4 ms·

> Everything was fine until I kinda felt my config.fish file got bloated and somehow nvm was kinda slowing down my shell startup. I'm quite happy with direnv t

by js2 5y ago

> Everything was fine until I kinda felt my config.fish file got bloated and somehow nvm was kinda slowing down my shell startup. I'm quite happy with direnv to avoid this problem. https://direnv.net/ https://direnv.net/ Funny enough, it was submitted to HN most recently just yesterday: https://news.ycombinator.com/item?id=30908321 https://news.ycombinator.com/item?id=30908321 direnv is complementary to the various language-version tools, so it obviates needing asdf: https://github.com/direnv/direnv/wiki#project-layouts https://github.com/direnv/direnv/wiki#project-layouts But it seems some folks combine the two: https://blog.mikecordell.com/2021/12/18/better-project-environment-management-with-direnv-and-asdf/ https://blog.mikecordell.com/2021/12/18/better-project-envir...

kot-behemoth 5y ago
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 https://github.com/direnv/direnv/issues/326). It can be a dealbreaker for some.
wyufro 5y ago
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.
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 ago
  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".
  - qbasic_forever 5y ago
    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.
    - Nextgrid 5y ago
      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.
    - oauea 5y ago
      How is that any different from actually running the software that requires the direnv?
      - qbasic_forever 5y ago
        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.
sph 5y ago
direnv is a killer tool in my arsenal. Writing 12 factor apps without it (especially managing configuration) is an exercise in pain and frustration.

by js2 5y ago

kot-behemoth 5y ago

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 https://github.com/direnv/direnv/issues/326). It can be a dealbreaker for some.

wyufro 5y ago

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.

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 ago
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".
- qbasic_forever 5y ago
  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.
  - Nextgrid 5y ago
    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.
  - oauea 5y ago
    How is that any different from actually running the software that requires the direnv?
    - qbasic_forever 5y ago
      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.

sph 5y ago

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