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

Where .env Went Wrong

secretspec.dev

Post reply on HN
Print view View original

51–60 of 77 posts

Re: Where .env Went Wrong

#51

Post by throw-the-towel »

jt2190 wrote: post #40
chacham15 wrote: post #39

This article reads like more of an ad than anything else. > Environment variables only deliver values Yes, the problem .env files try to solve is having "environment variables" be injectable from a file so that different applications can have different environment variables by default. > A string is not a schema Yes, input validation is an application concern. The application should know what these values represent /…

> Yes, the problem .env files try to solve is having "environment variables" be injectable from a file so that different applications can have different environment variables by default. This seems like a misunderstanding: The `.env` file should be `source`d into the current shell (environment). The application reads values using whatever mechanism it uses to read these values from the environment. Nothing should be…

Does it matter whether the app reads `.env` directly though?

Re: Where .env Went Wrong

#52

Post by e12e »

throw-the-towel wrote: post #51
jt2190 wrote: post #40

Earlier quoted context omitted.

> Yes, the problem .env files try to solve is having "environment variables" be injectable from a file so that different applications can have different environment variables by default. This seems like a misunderstanding: The `.env` file should be `source`d into the current shell (environment). The application reads values using whatever mechanism it uses to read these values from the environment. Nothing should be…

Does it matter whether the app reads `.env` directly though?

Maybe. How does the application unify different environment variables? Those inherited by the shell, those read from .profile, those set in the process that start the application (be that ./run.sh, a nodejs script, systemd etc...).

Re: Where .env Went Wrong

#53

Post by e12e »

throw-the-towel wrote: post #49

I can't understand for the love of me why our industry settled on env as The Way to store configuration. It's poorly discoverable, it's a shared namespace polluted by everyone and their `libdog`, it's stringly typed, etc. All of that just flies in the face of otherwise accepted dev wisdom. I love Django's approach to configs: your config is just a plain old Python file with some constants. As simple as possible, and…

Worst part they're too easy to accidentally check in to source control - and they bring user/workstation dependent settings into the work tree, rather than tuck them away in something like $HOME/. config/appname/local.env

Re: Where .env Went Wrong

#54

Post by wonger_ »

I'm working with .env and secrets and teamwide configs for the first time, trying to understand solutions from first principles.

Are these valid observations so far?

- .env is the simplest and oldest / most boring solution. Secrets are passed to teammates by DM?

- .env.example seems like a nice home for documentation about secrets

- but I'd rather avoid writing sensitive credentials at all -- instead, teams can use a cloud-based secrets manager and the project fetches secrets at runtime. Is this ever a hassle / any downsides? How standard is this practice these days? I hear this also helps updating secrets so you don't have to e.g. tell every teammate when you rotate a secret. Generally not a fan of introducing a network call and a saas dependency, tho

- non-sensitive environment variables also need a home. I don't like the idea of cluttering the project with a .env.local or worse like .env.development.local

- I hear lots of secrets and config management happens in container orchestration, but what if I barely have a container in the first place? I guess docker compose is one of the simplest tools at this layer?

I guess I'm just looking for a safe, simple solution for a small team, and maybe the problem is that every team does things differently, and that many tools are marketed towards huge enterprise teams.

Re: Where .env Went Wrong

#55

Post by gaigalas »

Likely a 12 factor legacy issue.

https://12factor.net/

This was really popular, and lots of people bought the factor III of only configuring via environment variables.

The whole point of it was: keep config simple. Env vars are austere and will keep you from complexity.

But people found a way to complicate them, so they could have both the 12 factor literal pass and the complexity they wanted.

That resulted in the mess we are today.

Re: Where .env Went Wrong

#56

Post by jpitz »

stilwe wrote: post #47

Hey cool, a relevant place to mention my project: https://dotprot.dev/ Type "dotprot" to copy your .env file into 1Password using the 1P CLI, it verifies it's there, then deletes the local copy of .env. When you're ready to work again, type "dotprot" again to restore the .env file from 1P. There is a .prot file in the directory that you can declare other files to store in 1P as well. Varlock ( https://varlock.dev ) i…

If 1Password hadn't jumped the subscription model shark, I'd be all over that. Any chance you'd entertain supporting bitwarden?

Re: Where .env Went Wrong

#57

Post by jpitz »

chis wrote: post #34

92% of this text is detected as AI. It may be time for Hackernews to integrate a Pangram detector into the UI, similar to what substack is doing :)

Why should HN pay for a questionable service when it already gets crowdsourced results for free?

Re: Where .env Went Wrong

#58

Post by ramses0 »

I wish there was better support for something like `SECRET_CMD="..."` (ie: "run this command to get/refresh secrets"), but that's just baking arbitrary command execution into your development pipeline.

Personally, I tend to have a `source ./source-me-auth` which does stuff like `DB_PASSWORD="$( pass show blah.com | head -1 )"`, but that still means I end up with secrets dangling around in my environment. The "source-me" file is safe to share, but my runtime environment is tainted (for good and bad...).

I saw something w.r.t. the way open-claw handles things where you basically say `export DB_PASSWORD="REDACTED@SECRET_001"` and then it basically outbound filters network requests to hydrate that with `s/REDACTED@SECRET_001/$REAL_SECRET/g`, and I _really_ like that mechanism b/c it defers secret usage to runtime and keeps it physically "out" of the application itself.

Basically, having `with $SECRETS -- some_app.sh --some params ...` wouldn't be terrible (conceptually).

Re: Where .env Went Wrong

#59

Post by theozero »

stilwe wrote: post #47

Hey cool, a relevant place to mention my project: https://dotprot.dev/ Type "dotprot" to copy your .env file into 1Password using the 1P CLI, it verifies it's there, then deletes the local copy of .env. When you're ready to work again, type "dotprot" again to restore the .env file from 1P. There is a .prot file in the directory that you can declare other files to store in 1P as well. Varlock ( https://varlock.dev ) i…

FYI - You can pull a whole .env style blob from a single item using varlock. Never written to disk and supports caching behind Secure Enclave.

Re: Where .env Went Wrong

#60

Post by BigTTYGothGF »

fhn wrote: post #29
s_dev wrote: post #26

Earlier quoted context omitted.

The fact that it's hidden means it doesn't get commited by accident in most git repos unless explicitly added or configured that way.

there shouldn't be any secrets in it so committing it shouldn't be a huge problem.

> shouldn't

Granted, but on the other hand: the entire history of this profession.

Post reply on HN