Hacker News Reader

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