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).

Direnv 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".

Yes, 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.

I 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.

How is that any different from actually running the software that requires the direnv?

The 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.

The same goes for your unit tests or just the application itself though

direnv 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

Unfortunately 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

I 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

I use direnv myself, and it's great. However, for anyone trying it out I'd caution that it doesn't play well with conda - the Python package management system (see this open issue https://github.com/direnv/direnv/issues/326). It can be a dealbreaker for some.

Indeed, direnv and asdf integrates, such that PATH is set to the values exposed by your .tool-config. This avoids the asdf shim and makes executing the tools slightly faster. Good when you have to run them over and over in a script.

direnv is a killer tool in my arsenal. Writing 12 factor apps without it (especially managing configuration) is an exercise in pain and frustration.