bug#44186: Recursive mkdir

Bengt Richter <[email protected]>
Newsgroups gmane.lisp.guile.bugs
Message-ID <20201025041350.GA14747@LionPure>
Hi divoplade,

On +2020-10-24 08:17:47 +0200, divoplade wrote:
> Hello,
> 
> Le samedi 24 octobre 2020 à 01:32 +0200, Bengt Richter a écrit :
> > An alternate solution could be programmed using ffi, as documented in
> > [1], n'est-ce pas?
> To be clear, you would rather have that function as guile code rather
> than extending the C function? I'm OK with that, but in which file
> should I put that function? My instinct was to put the code near the
> mkdir function, and that happened to be in a C file, so I went C.
>
Seems logical, and probably where I'd go, but please be careful!
Don't make a C version of this hack:
┌───────────────────────────────────────────────────────────────────────────────┐
│ (define (my-mkdir-p path . ignore) (system (string-append "mkdir -p " path))) │
└───────────────────────────────────────────────────────────────────────────────┘
You can then write (my-mkdir-p "foo-dir/bar-dir") and it'll do the job.

But it's definitely safer to skip the hack and write
┌─────────────────────────────────────┐
│ (system "mkdir -p foo-dir/bar-dir") │
└─────────────────────────────────────┘
and not give anything a chance to inject something bad via unsanitized parameters.
E.g.,
┌─────────────────────────────────────┐
│ (my-mkdir-p "here/below;tree here") │
│ here                                │
│ └── below                           │
└─────────────────────────────────────┘
It does the intended, so no suspicous change in that part, and 
my-mkdir-p looks innocent enough. (Did you notice the danger? ;)

Well, introducing something like this, but more subtle,
could be the first move by a mole  working for
<insert favorite bogeyman organization>
to compromise or disrupt/discredit GNU FLOSS competition.

Is that unhappy thought too paranoid?
I hope so, but I'm not convinced  ;/

> > What would guix best-practice guidance say about that?
> I'm not sure to follow, now this is a guile matter, guix has nothing to
> do about it. I'm sorry I messed a few things up with the mailing lists
> (I should have listened to them, "don't cross the streams"). Could you
> elaborate?
>
Sorry, you are right: it does become a guile matter, but...

... it also becomes part of guix if it's part of the guile version
a guix version depends on, so thereby it becomes a guix quality/security item
to be careful about.

So I was wondering whether guix architects have preferences
for where and how a function should be implemented, all things considered.

> Best regards,
> 
> divoplade
> 
-- 
Regards,
Bengt Richter
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.