> 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'.

▲

SOLAR_FIELDS 3 hours ago | parent | next [-]

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

	▲	hinkley 3 hours ago \| parent [-]
		Yeah I ended up finishing a Lava Flow Antipattern, where someone started wrapping of stdout and never finished it. We replaced every value for a key of 'token', 'password', 'secret' with 8 stars in the logs. 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.

▲

fragmede 3 hours ago | parent | prev [-]

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

	▲	hinkley 3 hours ago \| parent [-]
		I have on a number of occasions wondered if there's some way to make something like the 2 key system for nuclear launch protocols work for making destructive changes in production. I request an action, and it only takes effect if someone else repeats it. 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.