Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: From dotenv to dotenvx – better config management

dotenvx.com

Post reply on HN
Print view View original

151–160 of 223 posts

Re: Show HN: From dotenv to dotenvx – better config management

#151

Post by airtonix »

itchyouch wrote: post #149
skissane wrote: post #134

Earlier quoted context omitted.

> Instead, read secrets from a vault or from a file-system from _inside_ your process. I’ve never liked making secrets available on the filesystem. Lots of security vulnerabilities have turned up over the years that let an attacker read an arbitrary file. If retrieving secrets is a completely different API from normal file IO (e.g. inject a Unix domain socket into each container, and the software running on that cont…

I used to store secrets in the FS, and was told the best practice was env vars. Now it's not env vars. What is it then?

[dead]

Re: Show HN: From dotenv to dotenvx – better config management

#152

Post by qweqwe14 »

itchyouch wrote: post #149
skissane wrote: post #134

Earlier quoted context omitted.

> Instead, read secrets from a vault or from a file-system from _inside_ your process. I’ve never liked making secrets available on the filesystem. Lots of security vulnerabilities have turned up over the years that let an attacker read an arbitrary file. If retrieving secrets is a completely different API from normal file IO (e.g. inject a Unix domain socket into each container, and the software running on that cont…

I used to store secrets in the FS, and was told the best practice was env vars. Now it's not env vars. What is it then?

There isn't a right answer. It's just that people don't understand that one doesn't provide any meaningful benefit over the other (in the context of storing secrets), but the security "experts" are always eager to claim "X is insecure, do Y instead, it's best practice btw"

Unless I'm missing something, there are three scenarios where this comes up:

1. You are using a .env file to store secrets that will then be passed to the program through env vars. There's literally no difference in this case, you end up storing secrets in the FS anyway.

2. You are manually setting an env var with the secret when launching a program, e.g. SECRET=foo ./bar. The secret can still be easily obtained by inspecting /proc/PID/environ. It can't be read by other users, but so are the files in your user's directory (.env/secrets.json/whatever)

3. A program obtains the secret via some other means (network, user input, etc). You can still access /proc/PID/mem and extract the secret from process memory.

So I'm assuming that what people really want is passing the secret to a program and having that secret not be readable by anything other than that program. The proper way to do this is using some OS-provided mechanism, like memfd_secret in Linux. The program can ask for the secret on startup via stdin, then store that secret in the special memory region designed for storing secrets.

Re: Show HN: From dotenv to dotenvx – better config management

#153

Post by airtonix »

projektfu wrote: post #127
akvadrako wrote: post #123

Earlier quoted context omitted.

Encrypted with what key? Do you just mean obscured?

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?

Re: Show HN: From dotenv to dotenvx – better config management

#154

Post by [deleted] »

itchyouch wrote: post #149
skissane wrote: post #134

Earlier quoted context omitted.

> Instead, read secrets from a vault or from a file-system from _inside_ your process. I’ve never liked making secrets available on the filesystem. Lots of security vulnerabilities have turned up over the years that let an attacker read an arbitrary file. If retrieving secrets is a completely different API from normal file IO (e.g. inject a Unix domain socket into each container, and the software running on that cont…

I used to store secrets in the FS, and was told the best practice was env vars. Now it's not env vars. What is it then?

[deleted]

Re: Show HN: From dotenv to dotenvx – better config management

#155

Post by qweqwe14 »

NegativeK wrote: post #119
TZubiri wrote: post #113

Importing a set of library and dependencies to handle reading a plain text file poses more risks than just leaving the file unencrypted. You don't need to encrypt your keys, with what keys are you going to do so? Will you encrypt those? if someone is in your server you are pwned anyways. It's ok if you identify yourself as a cybersecurity dude and hold a cybersecurity role and you need to justify your livelihood. But…

> if someone is in your server you are pwned anyways. This is false and also a symptom of an all-or-nothing approach to cybersecurity, which isn't feasible in the real world.

Sorry but it is largely all-or-nothing in this case, if someone has access to the user the app runs as, you are screwed. It doesn't matter whether you use env vars or files.

I'm assuming the parent intended to say "if someone gained access to your user you are pwned anyways", which is true, unless you actually go to the effort of storing the secrets securely using OS-provided mechanisms. Env vars are not that.

> which isn't feasible in the real world

Well of course it isn't, how would you justify those sweet cybersecurity experts' paychecks otherwise? Not saying cybersecurity isn't important, but there's way too much snake oil in the industry nowadays (always has been?).

Re: Show HN: From dotenv to dotenvx – better config management

#156

Post by panzi »

Wait, it's also doing command interpolation? I missed that. Where is the code for that? I thought it uses dotenv-expand for interpolation, which can't do commands. dotenv-expand is already a bit meh, because of how it resolves the variables after parsing the dotenv file. Meaning you can't have a verbatim single quoted string and also you can get a stack overflow doing this:

    A=$B
    B=$A
Anyway, I hope they don't do command interpolation on top of that (like Ruby dotenv does), because then you can inject code via environment variables (like in the Ruby version).

I recently looked into various dotenv implementations just for fun. They're all different. No unified syntax at all. A lot don't do proper parsing either, but just use some regular expressions (like this one), which means they just skip over what doesn't matches. I started to document all the quirks I could find and wrote my own dotenv dialect just for fun. Nobody use it! Anyway, here it is: https://github.com/panzi/punktum

Direct link to the quirks of the JavaScript dotenv implementation: https://github.com/panzi/punktum?tab=readme-ov-file#javascri...

I've also tried to write a parser compatible to JavaScript dotenv (no x) in C++: https://github.com/panzi/cpp-dotenv

Re: Show HN: From dotenv to dotenvx – better config management

#157

Post by andrewmcwatters »

skissane wrote: post #134
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…

> Instead, read secrets from a vault or from a file-system from _inside_ your process. I’ve never liked making secrets available on the filesystem. Lots of security vulnerabilities have turned up over the years that let an attacker read an arbitrary file. If retrieving secrets is a completely different API from normal file IO (e.g. inject a Unix domain socket into each container, and the software running on that cont…

God this is such a prime example of how we just don't do security well enough industry wide, and then you end up with weird stupid stuff like encryption being an enterprise paid feature.

Secrets have to be somewhere. Environment variables are not a good place for them, but if you can't trust your filesystem to be secure, you're already screwed. There's no where else to go. The only remaining place is memory, and it's the same story.

If you can't trust memory isolation, you're screwed.

As a counterintuitive example from a former insider: virtually no one is storing secrets for financial software on an HSM. Almost no one does it, period.

Re: Show HN: From dotenv to dotenvx – better config management

#158

Post by andrewmcwatters »

itchyouch wrote: post #149
skissane wrote: post #134

Earlier quoted context omitted.

> Instead, read secrets from a vault or from a file-system from _inside_ your process. I’ve never liked making secrets available on the filesystem. Lots of security vulnerabilities have turned up over the years that let an attacker read an arbitrary file. If retrieving secrets is a completely different API from normal file IO (e.g. inject a Unix domain socket into each container, and the software running on that cont…

I used to store secrets in the FS, and was told the best practice was env vars. Now it's not env vars. What is it then?

The filesystem is fine, but we really shouldn't be using .env files that get loaded into environment variables due to them leaking in a few different ways.

Re: Show HN: From dotenv to dotenvx – better config management

#160

Post by cyberax »

slt2021 wrote: post #133
cyberax wrote: post #116

Earlier quoted context omitted.

> it might be easier to just store and checkout a single decryption key that only devops people know, "Devops people know" means that the key must be some secret property. Or you need to use the key during the deployment artifact building pipeline, and then deploy the artifacts with clear-text secrets. > vs storing hundreds of secrets. Then serialize them to JSON or whatever. > also it allows adding new secrets witho…

encrypted secrets are strictly an improvement over status quo of unencrypted secrets on disk - I dont understand why you make it seem like it is a bad idea? like what is the alternative you propose? storing plaintext secrets on disk and hope that your runtime is secure and hardened enough and free from vulnerabilities?? as if directory traversal, path injection vulnerabilities, shell command injection, etc vulns that…

> encrypted secrets are strictly an improvement over status quo of unencrypted secrets on disk

No. They are NOT. They are strictly worse than unencrypted data.

Unecrypted data is at least honest. Simply encrypting it and putting the key next to the data itself creates a dangerous illusion of security.

> like what is the alternative you propose? storing plaintext secrets on disk and hope that your runtime is secure and hardened enough and free from vulnerabilities??

Put secrets into your environment, don't store them on the disk.

If your code runs on AWS, then use AWS SSM or AWS Secrets Manager. If it's on Heroku, put secrets into the env vars. K8s has a secret manager. And so on.

Post reply on HN