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

181–190 of 223 posts

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

#181

Post by anentropic »

graemep wrote: post #179
itchyouch wrote: post #149

Earlier quoted context omitted.

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 problem with .env files is that you are doing both. You have a .env file that is in the same directory as your code and you just copy to to env vars at some point. This does not even meet the security principles that dotenv is supposed to implement! I think people are blindly following the advice "put secrets in env vars" without understanding that the point of it is to keep secrets outside files your app can rea…

Yes... surely the point of .env file is as a shortcut to provide env vars for local development

.env file shouldn't be used in production, env vars should be injected directly

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

#182

Post by wegfawefgawefg »

vitalysh wrote: post #172
jillesvangurp wrote: post #168

Earlier quoted context omitted.

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…

inject those variables via mount?

When you launch the docker containers you can pass in process env vars or do it via file. Nowadays people do this via kubernetes config yamls, which passes env to docker. Or rather they used to. Most people now use Helm charts which pass in the env to k8 yaml which pass them to docker. But then they feel its not secure enough... so a lot of people have the env split halfway between github actions secrets, and amazon secrets. The yaml for your github action config sends aws secret uri to the runner, which runs cdk which grabs the aws secret, and passes that to helm which makes k8 yamls, which passes the env to docker, which passes it to the process.

Then I killed myself and was reborn. Now I just use an env file.

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

#183

Post by jrockway »

brigadier132 wrote: post #26

Encrypting 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…

I've used git-crypt and sealed-secrets and the problem is always backing up the master key. sealed-secrets rotates it every so often so you need to go find it and copy it to 1password or whatever you use as your root of trust. (We used a calendar invite for this.)

git-crypt is easy, the master key doesn't rotate, so don't leak it. (Secret encryption key rotation is kind useless; it's nice that if you leak an old key newer secrets aren't leaked, but it depends on your underlying secret rotation policy as to whether or not that saves you any work. I have tended to do them in bulk in the past.)

On my last project we did disaster recovery exercises every 6 months, sometimes with the master key intentionally lost, and it wasn't that big of a deal. Restoring your infra-as-code involves creating the secret encryption service manually, though, which is kind of a pain, but not like days of downtime pain or anything. Of course, if the secrets encrypted your database or something like that, then losing the master key equals losing all your data. Hopefully your database backup has some solution for that problem.

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

#185

Post by iamsaitam »

stiiv wrote: post #81

dotenv has zero npm dependencies. dotenvx has 21, including a few I have never heard of. Is this really more secure?

This is quite a common remark when it comes to Javascript. I rarely see the same being made about Rust libs, which also rely heavily on external dependencies.

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

#186

Post by csomar »

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?

Not using env vars is security through obscurity. If someone has ssh access to your container, it doesn't matter whether the secrets are on a file or on memory. The attacker has as much access as the app itself.

On the other hand, using .env vars can leak in different ways like a developer mistakenly committing secrets to git or making this file available to the world wide web.

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

#187

Post by maleldil »

sandstrom wrote: post #79

I'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…

Seconded. I changed from pyenv to mise because pyenv was slowing down my shell startup (probably the shims, which mise doesn't use by default), and I'm slowly using mise for more stuff. Right now, I'm using it to auto-turn on virtual environments and add project scripts to the PATH, and it works very well.

I haven't felt the need to use it as a task runner yet, but that's probably because I'm used to having a bunch of shell and Python scripts in a `scripts` folder.

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

#188

Post by progx »

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?

The "securest" way is, you start your app and the app awaits the input of the key, it is only in the RAM.

But in reality, nobody will do that.

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

#189

Post by merb »

qweqwe14 wrote: post #152
itchyouch wrote: post #149

Earlier quoted context omitted.

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 passe…

Also for 3. you just added another supply chain issue and another thing to maintain and keeping up to date, which is probably worse
Post reply on HN