dotenv has zero npm dependencies. dotenvx has 21, including a few I have never heard of. Is this really more secure?
Show HN: From dotenv to dotenvx – better config management
81–90 of 223 posts
Re: Show HN: From dotenv to dotenvx – better config management
#82Earlier quoted context omitted.
This is still “env vars”, easy to read from /proc/*/env too see the decrypted secrets from a different process. Versus in-process only secret fetch where you’d need to scan the memory pages of the app, which is a bit harder - especially if you keep the credentials in memory in a scrambled format so a simple scan on process memory for “secret_prefix_” doesn’t find them.
If an attacker can read other processes' envs you've pretty much lost as they're 1. Inside your process which means they can see the decrypted values. 2. Root which means they can get into your process to see the decrypted values. I'm not sure if your average dev has a threat model that assumes in memory scrambling let alone leaked env vars. After all we're talking about the standard way to do it being populating a f…
I’m advocating people use something like SecretsManager, not this thing. In-memory only > env vars > secret files on disk.
I find env vars very precarious because harmless developer debug logging, actions like sshing into a container and typing `env` etc can easily expose them.
File on disk can be read by an attacker with via subdirectory path traversal bug
It’s much less likely for in process only secrets to be exposed by common mistakes/bugs
Re: Show HN: From dotenv to dotenvx – better config management
#83I've started using Mise for some stuff at work. Haven't digged in a lot yet, but looks really promising. https://mise.jdx.dev/ It handles task running (wipe local test db, run linting scripts, etc), environment variables and 'virtual environments', as well as replacing stuff like asdf, nvm, pyenv and rbenv. Still somewhat early days, tasks are experimental. But looks very promising and the stuff I've tried to far (ta…
I second mise, it's been a nice replacement for direnv, asdf and makefiles for my use case. Much faster, still compatible with the old configuration files when needed and all in one tool for the new projects. Awesome.
Re: Show HN: From dotenv to dotenvx – better config management
#84We’ve been pushing for committing encrypted secrets for many years now, and have written an open source spec and implementation in multiple languages: https://github.com/neosmart/securestore-rs
I don’t get it. There’s a symmetric secrets.key that anyone could get hold of and use to overwrite secrets? No thanks.
And where do I keep the key? In a secret store?
Re: Show HN: From dotenv to dotenvx – better config management
#85There's a typo in the article, if the author reads this : > But I think we have a solution to all three today - with dotenvx. In reverse problem order The URL in `dotenvx` points to https://gitub.com/dotenvx/dotenvx (gitub without the h)
Hey this link is malicious. It redirects to location: http://ww99.gitub.com/dotenvx/dotenvx and then some site blocked by ublock
Re: Show HN: From dotenv to dotenvx – better config management
#86[flagged]
Re: Show HN: From dotenv to dotenvx – better config management
#87I _detest_ this kind of encryption. It's literally worse than useless. It makes life much harder during debugging, and it eventually leads to developers just storing the decryption keys locally. For this kind of encryption to work, you need to supply the decryption key from some outside system (e.g. via env vars, AWS SSM, etc.). And if it can supply the key, then why not just use it for other important secrets direct…
it might be easier to just store and checkout a single decryption key that only devops people know, vs storing hundreds of secrets.
while developers can move around their .env file across systems without worrying that they left plaintext secrets somewhere.
also it allows adding new secrets without knowing decryption key - I think it is important for collaboration
also most importantly: plaintext decrypted secrets are never stored on disk, and only kept in memory. I think it is also an improvement towards the regular doting
Re: Show HN: From dotenv to dotenvx – better config management
#88I think it's good advice to not pass secrets through environment variables. Env vars leak a lot. Think php_info, Sentry, java vm dumps, etc. Also, env vars leak into sub-processes if you don't pay extra attention. Instead, read secrets from a vault or from a file-system from _inside_ your process. See also [1] (or [2] which discusses [1]). Dotnet does this pretty good with user secrets [3].
[1] https://blog.diogomonica.com/2017/03/27/why-you-shouldnt-use... [2] https://security.stackexchange.com/questions/197784/is-it-un... [3] https://learn.microsoft.com/en-us/aspnet/core/security/app-s...
Re: Show HN: From dotenv to dotenvx – better config management
#89dotenv has zero npm dependencies. dotenvx has 21, including a few I have never heard of. Is this really more secure?
[deleted]
Re: Show HN: From dotenv to dotenvx – better config management
#90I don't think this is the best approach. I am building https://phase.dev which lets you import secrets (.env), encrypt secrets (end-to-end encrypted with keys you control), sync them to other services/platforms (think AWS, GitHub, Kubernetes), and inject them into applications at runtime (e.g., phase run node index.js).