We Are Forking dotenvy into dotenv-ng
secretspec.dev
secretspec.dev
So no, if anything direnv makes you hip and edgy.
Direnv is the right way to go if you want a tool for this. Otherwise dotenv's implementation in bash is essentially `set -a; source .env`. Look ma, no custom parser!
Seems really silly to have a library do what two lines of shell can reasonably accomplish.
Which is dumb. The canonical spec for .env should just be "whatever POSIX sh does."
One of the major benefits of a shell-based approach is your env vars could be generated from the output of a command.
Which can be trivially used to populate secrets from whatever your secret store of choice is.
Now we've also cleanly solved secret distribution for developers with one less dependency!
Though the obvious fix is to use single quotes in the .env file.
I also really like that for sensitive variables (AWS tokens, prod DB passwords, etc), I can keep those in a dedicated secret store (I use 1Password for personal projects and there are more enterprise focused alternatives for work).
direnv does one thing really well, and it enables a large ecosystem of other components that you can pick and choose to build developer environments. SecretSpec, from the featured article, is one such component which pairs really well with direnv, and has the features you’re describing for secrets.
I think direnv’s approach is the one with more staying power.
It also doesn't work well. And they have no support outside of Discord chat.
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'.
We were using Splunk and if you're handing third parties your secrets, you're gonna have a bad time. Sooner or later they'll have a disgruntled employee or a breach.
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.
The problem though is priming, and a two key system only fixes that the first couple times. In a year you're right back where you started. Because once I've suggested a course of action to you, the Primacy Effect makes you key your counterproposals to my initial bid, and if I'm enough off the mark we end up off the mark together. Add Recency Effect on top of it - if I haven't been wrong the last ten times I asked you to spot me, you slowly stop assuming I'm wrong this time. When the production outage happens, it comes out that your thought process was that I know what I'm doing and you didn't 'need' to be there for the last five times so you've zoned out and didn't catch my mistake.
And if I start my ask by sending you a URL, if I cut and pasted the wrong URL you're stuck looking at the wrong thing with me and we both sail off into the canyon together.
Still, if I'm careful to give you only the high-level request, and we derive the same solution from that request, then maybe a tool like that would still be useful. But the most important part of that interaction is still outside of the scope of any tool that could sanity check us. It's just process.
I have a shell function for this in my zsh config:
function lenv() {
export $(cat .env | xargs)
}
If you maintain one shell per process-that-needs-a-secret-in-the-env then it doesn't matter, but if you're using long-running shells then direnv can load and unload env vars. It also gives you a nice little heads-up that it loaded/unloaded variables.
#!/bin/sh
set -a
. ./.env
exec "$@"I'm not trying to persuade that these tools are essential or anything, just highlighting that there's a few small details some take care of that're fairly nice.
If you really believe .env was a mistake (it was), just let it die. You are the ones keeping it alive now.
Instead of migrating to dotenv-ng, these users could be putting effort into migrating away from .env files entirely.
edit: I understand SecretSpec needs to parse .env files exactly like Node.js’s dotenv library, which doesn’t support interpolation, to make it easier for these projects to use SecretSpec.
I’m saying making this a standalone library is bad. Rust projects will pick this up and use it instead of SecretSpec, and users of the unmaintained Rust crate will migrate to it.
This feels like the exact type of solution a badly prompted and poorly piloted AI tool manically follows to an absurd conclusion if you don't step in and tell it to do it the obvious and correct way instead of re-inventing the wheel.
(I would also argue most of the point of a .env file being what it is that you can source it in a shell? Does the author here have any sane argument for not using a yaml/json/whatever file and XKCD-927ing it instead? Is this not just introducing a flaw when `source .env` stops behaving like expected?)
“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.”
I assume you just mean normal [env] in mise.toml which is different, but this still is relevant to mise
It’s not a great convention.