Ludovic Courtès schreef op ma 04-10-2021 om 10:22 [+0200]: > Hi, > > "pelzflorian (Florian Pelz)" skribis: > > > On Sat, Oct 02, 2021 at 03:40:00PM +0200, Ludovic Courtès wrote: > > > "pelzflorian (Florian Pelz)" skribis: > > > > On Sat, Oct 02, 2021 at 12:21:16PM +0200, Ludovic Courtès wrote: > > > > > 2. ‘guix shell’, without arguments, loads ‘guix.scm’ or ‘manifest.scm’ > > > > > from the current directory or one of its ancestors. > > > > This however is concerning. Users will not expect guix to execute > > > > arbitrary code. Maybe print a suggestion to maybe --file the file > > > > instead. > > > I think it’s fine as long as, as in the case of ‘haunt build’ or ‘make’ > > > or ‘git’, it’s properly documented. Also, ‘guix shell’ unconditionally > > > writes a message. > > > > Let’s say I have downloaded undesirable code to a file > > /home/florian/Downloads/guix.scm and am hacking on source code in > > /home/florian/Downloads/something/ where I run `guix shell`, but > > /home/florian/Downloads/something/ does not in fact contain a > > guix.scm file. Now I’d have accidentally run the other guix.scm. > > Sure, but it’s all under your control; it’s not very different from > someone knowingly running “guix build -f guix.scm” on an untrusted file, > is it? Consider the following situation: 1. I browse the web and find some rando's website. It has a link to a "guix.scm" to download. 2. I'd like to know how people are using guix, so I tell IceCat to download it. IceCat downloads it to ~/Downloads/guix.scm. 3. I forget about the guix.scm and didn't look at it. 4. I download some tarball, verify it (with gpg or something), unpack it, and run "guix shell" without arguments from within the directory (e.g. ~/Downloads/some-source-code). 5. It turns out the tarball didn't actually have a guix.scm, so the ~/Downloads/guix.scm from the rando is loaded. 6. It turns out the rando's guix.scm uploads my secret keys, passwords, all e-mails, installs a keylogger ... Oops! > > Also `make` is typically used without arguments, but a novice `guix > > shell` user might know `guix shell program-a program-b` but is > > surprised when running `guix shell` without arguments in an untrusted > > directory. > > We have the advantage that ‘guix shell’ is a new command, so we can > document it from the start as behaving this way without arguments. Sure, this behaviour can be documented, but it's very easy to forget a piece of documentation, especially if the behaviour is inconsistent between "guix environment" and "guix shell", and an attacker only needs an attack to function once. I'd prefer not be constantly kept on my toes, so if "guix shell" will automatically load guix.scm in the current directory or parent directories, I think I'll keep using "guix environment" to avoid any opportunities for fatal mistakes. Greetings, Maximes.