Show HN: From dotenv to dotenvx – better config management

Post by jen20 » Wed, Jun 26, 2024, 11:47 AM UTC

jillesvangurp wrote: post #168

cimnine wrote: post #88

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

Disagree here. Basically if you use docker (which for most of the stuff you mention, you should), environment variables are pretty much how you configure your docker containers and a lot of sever software packaged up as docker containers expects to be configured this way. Building a lot of assumptions into your containers about where and how they are being deployed kind of defeats the point of using containers. You s…

Post by progx » Wed, Jun 26, 2024, 11:57 AM UTC

randomdata wrote: post #10

boxed wrote: post #3

I don't get it. Dotenv is only good for local dev. Otherwise you should put your secrets in environment variables (the "env" in ".env"). That people put .env files in prod is a mistake itself, and the proposed fixes here seem to not really do much about that.

Dotenv is an okay hack, but the root problem is that the operating systems we run these applications in don't have a fully conceived environment variable system. I think you have a fair point that dotenvx doesn't get the implementation right, but it does at least seem to recognize where the problem lies and is trying to fix it from that angle. You have to start somewhere. Almost never do we get solutions right the fi…

Post by michaelmior » Wed, Jun 26, 2024, 1:05 PM UTC

bluelightning2k wrote: post #132

michaelmior wrote: post #48

With leaking secrets being such a big concern, it seems wise to require that secrets be encrypted to use dotenvx. That is, it will only work with encrypted secrets. As others have commented, this doesn't eliminate the risk entirely, but I think having a tool that doesn't support unencrypted secrets at all, although a bit less convenient, is a win.

Not all env vars are secrets. About half is just regular config. If mandatory how would it know what's a secret?

Post by michaelmior » Wed, Jun 26, 2024, 1:07 PM UTC

airtonix wrote: post #153

projektfu wrote: post #127

Earlier quoted context omitted.

The utility has a means of encrypting them with public key cryptography so that the plaintext is never in your development directory. GP thinks this should be made mandatory.

point is: where and how you do get this key when in prod?

Post by politelemon » Wed, Jun 26, 2024, 1:12 PM UTC

gkfasdfasdf wrote: post #109

wodenokoto wrote: post #45

On my phone so can’t double test, but can’t you get this by adding “export” in front of every line in your env file and then source before running command? I suppose if you don’t want it to stay after execution i believe you can: > $(source .env; my command) I’m sure there is a fairly straightforward way to encrypt and decrypt a local file

If in bash, you can use the 'allexport' option and source the .env without having to add 'export' in front of every line: #!/bin/bash set -o allexport . .env set +o allexport cmd