4 ms·
direnv is nice but it really makes me uneasy if it catches on for modern collaborative development. You are giving people a _ton_ of trust when cloning a repo
by qbasic_forever 5y ago
direnv is nice but it really makes me uneasy if it catches on for modern collaborative development.
You are giving people a _ton_ of trust when cloning a repo or pull request that has a .envrc which will be automatically executed by direnv. This file could do anything from steal your SSH keys to delete your entire home directory or worse. And the only thing preventing that from happening is the suggestion of "oh be sure to eyeball the .envrc file and make sure it looks ok, then run this command to enable it". People will just google for the first "how to I unblock .envrc file" and blindly run the command, then oops. Or a determined attacker will just obfuscate what they're doing so the .envrc looks fine but you failed to realize some esoteric bash-isms were actually invoking an obfuscated script and... oops. It's just begging for a supply chain disaster on a similar scale as npm's infamous issues.
VS code and some vim extensions have similar issues with automatic project-specific configurations that allow arbitrary code execution too, and neither have a good solution beyond 'just read all the code and understand it to make sure it's not going to hurt you'. It's not really a unique thing to direnv.
We really need a better model for collaboration and consistent dev environments. I think containers and docker/chroot/etc. environments with explicit opt in of your local resources, configs, files, etc. are a much more sane and security conscious path towards it. A script executing to setup my python environment for a project should never, ever have access or even know about my personal password store database for example (unless I explicitly decide it should).
- Nextgrid 5y agoDirenv maintains a local cache of the scripts it's allowed to execute. It will not execute a brand new script and instead ask you to manually run "direnv allow".
- qbasic_forever 5y agoYes, that's why I explicitly mentioned this: > And the only thing preventing that from happening is the suggestion of "oh be sure to eyeball the .envrc file and make sure it looks ok, then run this command to enable it". People will just google for the first "how to I unblock .envrc file" and blindly run the command, then oops. Or a determined attacker will just obfuscate what they're doing so the .envrc looks fine but you failed to realize some esoteric bash-isms were actually invoking an obfuscated script and... oops. You need to be absolutely sure you've read and understand every single line in the .envrc file, and every single line in any script it may be invoking, before you run direnv allow. Otherwise you are giving code from the internet a blank check to do anything on your machine with your user account. I personally do not think bash/shell is a sensible language to trust that you can quickly or easily determine from a visual check alone if a script might be doing nefarious things.
- Nextgrid 5y agoI use direnv to source environment variables - the only scripts I use it for consist of "export" statements. Anything beyond that and I'll be questioning it. Sure, you can trick idiots into running malicious code, but I don't think you need direnv for that - any pip/npm install can run anything and so does curl|bash.
- oauea 5y agoHow is that any different from actually running the software that requires the direnv?
- qbasic_forever 5y agoThe pull request scenario is what scares me. Someone sends you a drive by pull request that has a ton of changes and you don't notice they slipped an obfuscated bash quirk into the .envrc (along with legitimate changes to the file) that invokes their obfuscated nasty script. You pull down the change, approve the envrc (looks fine!), and poof there goes your home directory or worse.
- oauea 5y agoThe same goes for your unit tests or just the application itself though
- DandyDev 5y agodirenv actually won't run anything until you explicitly allow it to. And if the .env file changes, you have to re-allow direnv to read and execute it. Seems safe to me
- qbasic_forever 5y agoUnfortunately like the other comment you didn't read what I said and my concern about this approach. Please see my response: https://news.ycombinator.com/item?id=30922199 https://news.ycombinator.com/item?id=30922199
- hardwaresofton 5y agoI don’t include the env file in the source, but rather include a sample in the README. If I wanted to include it, I use something like git-crypt and encrypt the contents