On 2024-11-11 09:54, Saku Laesvuori wrote: > Is it common to source other files from direnv or do people normally > just set environment variables and run programs from system PATH? If > sourcing other files is very rare with direnv and very common with guix > shell, comparing the security models is not as useful. I have never used > direnv, so I don't know. Maybe it is also often used to source > semitrusted files.
In the Nix/Guix space, I guess it's pretty common. At least I do use it this way (if I need environment variables for emacs or git to behave as intended in a project for instance). Outside these projects it makes less sense, but I think it's where it's most used. One example from my resources directory which requires some env variables for a git hook to run properly : export PYTHON="$(cd /tmp && guix shell python-wrapper python-tree-sitter python-pygit2 tree-sitter-bibtex -- which python)" export PYTHONPATH="$(echo $PYTHON | cut -d/ -f-4)/lib/python$( $PYTHON -V | cut -d' ' -f2 | cut -d. -f-2 )/site-packages" export TREE_SITTER_BIBTEX_PATH="$(echo $PYTHON | cut -d/ -f-4)/lib/tree-sitter/libtree-sitter-bibtex.so" >> I guess there are two use-cases : >> 1) scheme development with guix.scm loading local changes: Indeed this >> change is not really improving security, but neither is it harmful. > > This case is a bit broader than just scheme but yes, the change does not > really have an impact here. The projects I refered to are mostly written > in Haskell. I load the package definitions from other files to > guix.scm/manifest.scm just to make the repositories work cleanly as Guix > channels. > >> 2) custom manifest.scm in non-scheme projects (my use-case): Often in >> this case you would only change your manifest.scm, and it indeed >> increases security (the alternative would have been to automatically add >> the -m manifest.scm option but I'm not feeling secure with this >> alternative). >> More on my use-case: https://lists.sr.ht/~abcdw/rde-devel/patches/54944 > > Yes, but only slightly, I think. Because loading code from other files > is normal with guix manifests (see above), an attacker would first > refactor the repository into a guix channel to introduce loading from > another file in a non-suspicious way and only after that include the > malicious code. Agreed. Though the user has to accept the introduction of loading from another file though, this is what is better in this system IMO. In my use-case, transforming into a guix channel wouldn't make sense. > Anyway, I am not opposed to this change. The only effects for my use > cases are positive (nicer UI with the --allow flag). I just want to > point out that I don't think this makes any attacks significantly > harder. Agreed on the significantly. Let's just not give a false security guarantee in the commit/news/manual, the user still has to be careful. -- Best regards, Nicolas Graves
