> But migrating away from .env starts with reading it correctly.
We had a system that mediated all access to the static config through an in-house library. Because nobody touched the environment-specific data directly, it was a convenient spot to layer on reloadable configuration from a Raft source, and fold in environment-specific secrets coming through an old 12 Factor solution, although we could have also integrated some other secrets management as well.
Or, left it as a separate API. That tends to work for tired and distracted people well. Having security related stuff use a unique code pattern to access it does, I find, help keep people from treating it all the same way they treat other data, which is to throw it around profligately and occasionally write it to the logs. The moral equivalent to the guard over the missile launch switch versus the machine gun trigger. One of those has much more forgiving failure modes than the other.
It's the same problem 'capability' based systems frequently run into - capabilities end up meaning that if you can see something you're entitled to use it. And when your coworkers add new features to the system, you end up accidentally being able to see things you shouldn't be able to see.
Java for instance ran into this rather frequently with theirs. Someone would add an object to the global state and not notice that some peer added a reference to a reference to that object with proprietary data the client code wasn't meant to have at all. Information wants to be 'free'.
I think there are two separate concerns here. The idea that long lived secrets survive in plaintext on a disk somewhere is a bad idea that should go away, but also tangential to that people have to have good hygiene around not printing evil things to logs. Latter is a lot harder to catch imo, and is a separate problem
It’s an open source project, so you don’t have to wish it.
“Hey dotenvy team, I’m a fan of your project and wanted to help out. I noticed that some of your announcements are AI generated, and would like to help bring back the human voice. I’ll be happy to proof read and/or write your blog posts and release announcements in the future. Let me know if this is something you could use.”
.env is self sustaining at this point. The functionality described in the post exists to help move people off of it. It’ll have a better chance of dying when fewer people use it and that starts with making it easy to move away from it.
> But migrating away from .env starts with reading it correctly.
We had a system that mediated all access to the static config through an in-house library. Because nobody touched the environment-specific data directly, it was a convenient spot to layer on reloadable configuration from a Raft source, and fold in environment-specific secrets coming through an old 12 Factor solution, although we could have also integrated some other secrets management as well.
Or, left it as a separate API. That tends to work for tired and distracted people well. Having security related stuff use a unique code pattern to access it does, I find, help keep people from treating it all the same way they treat other data, which is to throw it around profligately and occasionally write it to the logs. The moral equivalent to the guard over the missile launch switch versus the machine gun trigger. One of those has much more forgiving failure modes than the other.
It's the same problem 'capability' based systems frequently run into - capabilities end up meaning that if you can see something you're entitled to use it. And when your coworkers add new features to the system, you end up accidentally being able to see things you shouldn't be able to see.
Java for instance ran into this rather frequently with theirs. Someone would add an object to the global state and not notice that some peer added a reference to a reference to that object with proprietary data the client code wasn't meant to have at all. Information wants to be 'free'.
I think there are two separate concerns here. The idea that long lived secrets survive in plaintext on a disk somewhere is a bad idea that should go away, but also tangential to that people have to have good hygiene around not printing evil things to logs. Latter is a lot harder to catch imo, and is a separate problem
> the guard over the missile launch switch
That's called a molly guard, but also a Debian package that asks you before you run shutdown if you're on the server you intended to shut down.
What does the ng at the end means? I have seen a few products/projects that added it and no explanation of the meaning.
Next generation I guess.
I love AI development, but I wish product announcements were self-authored.
It’s an open source project, so you don’t have to wish it.
“Hey dotenvy team, I’m a fan of your project and wanted to help out. I noticed that some of your announcements are AI generated, and would like to help bring back the human voice. I’ll be happy to proof read and/or write your blog posts and release announcements in the future. Let me know if this is something you could use.”
Can’t you just escape the dollar sign?
If you really believe .env was a mistake (it was), just let it die. You are the ones keeping it alive now.
.env is self sustaining at this point. The functionality described in the post exists to help move people off of it. It’ll have a better chance of dying when fewer people use it and that starts with making it easy to move away from it.
How exactly changing a default that users rely on is going to make it easy to move away from it?
Instead of migrating to dotenv-ng, these users could be putting effort into migrating away from .env files entirely.
doppler all the way