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

41–50 of 77 posts

Re: Where .env Went Wrong

#41

Post by preommr »

domenkozar wrote: post #32
eigencoder wrote: post #19

Hm, I haven't seen these issues personally. We only have one `.env` file and it's just for local secrets. Configuration emphatically does not go in `.env` and ideally is in docker compose and defined in code (we use Pydantic Settings).

https://x.com/NoeticsTech/status/2071136897985138897 https://x.com/0xPrajwal_/status/2084163731534311627 https://x.com/nilbuild/status/2084339074639200488 The issue is that agents need structure and context.

No it isn't.

Your local .env should NOT be shared, but should also be assumed to be leaked at any given time. Security should be done using a secrets manager through the cloud platform that's being used, e.g. AWS'secrets manager (or ssm param store too i guess)

Pasting it into chatgpt should not be a problem.

It also doesn't belong in git repos, but a much bigger issue is what process led to it. It's pretty standard to ignore it in a .gitignore, I'd be very surprised if modern agents made that mistake. And even if they did, agents should call tools that scaffold deterministically so that this isn't a problem.

I genuinely don't even know what we're talking about anymore, .env files are just values (it even says so in the article). People are making it way more complicated than it needs to be for no discernable reason other than an insane amount of laziness.

Re: Where .env Went Wrong

#42

Post by chis »

devmor wrote: post #36
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 :)

I’m not saying whether I think you’re right or wrong, but AI text detectors don’t work and never will.

This has been pretty well studied. Pangram is about as good at an expert human with a 98% detection rate and https://arxiv.org/pdf/2501.15654

Re: Where .env Went Wrong

#43

Post by weinzierl »

I see many .env files with unquoted values, like the first example in OP

   REDIS_URL=redis://localhost:6379
and it triggers me big time. Always quoting shell variable values is so deeply ingrained from very painful experiences decades ago that it still causes a somatic flashback whenever I see it.

This is what went wrong with .env

Yes, I know

    docker --env-file
doesn't work with quotes but that's just docker being broken and why they fixed it in docker compose.

Also see jt2290's comment:

https://news.ycombinator.com/item?id=49171684

Re: Where .env Went Wrong

#45

Post by TZubiri »

.env files are fine, as long as you don't import a random dependency to open and read a file. If you think about it for ten seconds, it's unjustifiable, and it's only done because others do it.

Re: Where .env Went Wrong

#47

Post by stilwe »

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 ) is also good for this and more mature. I use it on some work projects, but for local dev, I wanted something to allow me to be even lazier than that.

Re: Where .env Went Wrong

#48

Post by deathanatos »

s_dev wrote: post #26
KevinMS wrote: post #22

> Where .env Went Wrong start with making it a dot file. Why would you want to hide the fact your app was using loaded environment variables?

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.

No, it won't.

  ~/code
  » cd foo
  ~/code/foo
  » git init
  ± foo:main:/
  » touch .env
  ± foo:main:/
  » git add .
  ± foo:main:/
  » g s
  On branch main
  
  No commits yet
  
  Changes to be committed:
    (use "git rm --cached ..." to unstage)
   new file:   .env
  
  ± foo:main:/
  »
File is added, kaboom. "It should be in .gitignore" yes, true, but that has nothing to do with it not getting committed because it is hidden.

And even with it in .gitignore, I've dealt with multiple security incidents where someone has managed to commit it anyways. (And yes, I'm aware there are commands to do this, but what I haven't figured out is why someone would work around the safety and not think "what's the point of this?" prior to the bullet ending up in the foot.)

Re: Where .env Went Wrong

#49

Post by throw-the-towel »

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 works great.

Re: Where .env Went Wrong

#50

Post by LeBit »

prologic wrote: post #37

This is why I love direnv (the tool) and just a simple .envrc (not .env). It has none of the problems posited in the OP's article. It assumes nothing, only that direnv manges loading up the .envrc into your shell.

I moved from direnv, asdf and Task combo to mise.

Mise env vars management is much better. If you really need a script to generate env vars (like what you can do with direnv, there is a clean mechanism for that).

If you need to do something when you enter the directory of a project, there is also a mechanism for that.

Mise is really nice.

Post reply on HN