Can someone help enlightening me. In terms of preventing leaks, since we still need to ensure that the .env.keys doesn't leak, wouldn't effort still be the same?
The ability to use arbitrary filename for.env is quite nice though!
Show HN: From dotenv to dotenvx – better config management
141–150 of 223 posts
Re: Show HN: From dotenv to dotenvx – better config management
#142How would this work with application-specific Intellij Run/Debug configurations? Would this require switching to a "Shell Script" configuration, thereby losing debugging capability etc?
Re: Show HN: From dotenv to dotenvx – better config management
#143I 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…
[deleted]
Re: Show HN: From dotenv to dotenvx – better config management
#144https://github.com/dotenvx/dotenvx
[deleted]
Re: Show HN: From dotenv to dotenvx – better config management
#145Can someone help enlightening me. In terms of preventing leaks, since we still need to ensure that the .env.keys doesn't leak, wouldn't effort still be the same? The ability to use arbitrary filename for.env is quite nice though!
The idea is that the private key is stored outside of your configuration directory (e.g. in your OS's keychain), so your dotenv file can contain encrypted key values without leaking the value itself.
Re: Show HN: From dotenv to dotenvx – better config management
#146Encrypting secrets and committing them seems very convenient but I'm paranoid about these sorts of things. Can anyone tell me why this would be a bad idea? One reason I can think of is that normally with secrets I actually don't keep any copies of them. I just set them in whatever secret manager my cloud environment uses and never touch them again unless I need to rotate them. Meaning there is no way to accidentally…
The biggest issue with storing secrets in version control with the code is that past secrets are never relevant after they have been rotated. This makes rollbacks risky. Consider: 1. Create secret v1 2. Code v1 3. Deploy 4. Secret v2 (rotation) 5. Code v2 6. Deploy 7. Oops, need to roll back to v1 (from step 2) 8. Outage, because the secrets in step 2 are not the secrets from step 4
This seems trivially solved by never mingling secret rotations with general deployments?
Re: Show HN: From dotenv to dotenvx – better config management
#147Env vars over-share and files depend on local permissions. We should have a capabilities -like way to send secrets between processes. e.g., decrypt and expose on a Unix socket with a sha filename that can only be read from once, and then gets torn down. Share the file name, target can read it and immediately the secret is now at-rest encrypted.
Encryption based on config containing a whitelist of ssh public keys and what they can access, sort of like age.
Re: Show HN: From dotenv to dotenvx – better config management
#148This is similar to how Rails handles secrets - https://edgeguides.rubyonrails.org/security.html#environment... In Rails, the entire file is encrypted unlike here where only the secrets are
How do reviewers of a PR know when/which environment variables changed?
Re: Show HN: From dotenv to dotenvx – better config management
#149I 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…
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?
Re: Show HN: From dotenv to dotenvx – better config management
#150Earlier 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?
Well, I’d be the first to admit that we have a gap here, the solution that I personally would consider ideal doesn’t seem to actually exist, at least on the server-side.
If we are running under something like K8S or Docker, then I think there should be some component that runs on the host, that provides access to secrets over a Unix domain secret, and then we mount that socket into each container. (The reason I say a Unix domain socket, is so then the component can use SCM_CREDENTIALS/SO_PEERCRED/etc to authenticate the containers). I’d also suggest not using HTTP, to reduce the potential impact of any SSRF vulnerabilities (although maybe that’s less of a risk given many HTTP clients don’t work with Unix domain sockets-or at least not without special config). (Can we pass memfd_secret using SCM_RIGHTS?)
For desktop and native mobile, I think the best practice is to use the platform secret store (Keychain on macOS/iOS, Freedesktop Secret Service for desktop Linux, Android Keystore, Windows Credential Manager API, etc). But for server-side apps, those APIs generally aren’t available (Windows excepted). Server-side Linux often lacks desktop Linux components such as Freedesktop APIs (and even when they’re present, they aren’t the best fit for server-side use cases)