But the encrypted API key doesn't work, it needs to be decrypted first. Let's give the server access to the private key so it can decrypt the API key. We can do this by putting the private key in an env var. But now the private key is unencrypted. Ah, it doesn't work.
You’re thinking too much. When you run the app, the system decrypts the secrets and makes them available as env vars (or some other mechanism).
In an admin ui, you list the names of secrets only, and provide a “reveal” or a “replace” on each one. They are never decrypted unless explicitly asked for.
Is this perfect? Absolutely not. The key is controlled by the company, but it can be derived in a manner that doesn’t allow for the dump of everything if it’s leaked.
My gripe is that, if some additional authentication is then not required for deployments or SSH access, that whoever has access to the admin UI will still be able to access the box and extract all secrets, just with extra steps. There's usually no real security boundary between "admin UI controls the box" and "box requires secrets in plain text".
I still like the approach, but I'm afraid that it feels more secure than it is, and people should be aware of that.
It’s absolute baseline, but yes, it relies entirely on the platform’s permissions model, the administrator who assigns permissions, and the application authors to not create vectors for env var dumps. :)
But honestly, if you’re in the container, and the application running in the container can get secrets, so can a shell user.
_Maybe_ there’s a model where the platform exposes a Unix domain socket and checks the PID, user, group of the connection, and delivers secrets that way? This has its problems, too, like it being non-standard, only possible in some scenarios and otherwise fallible… but better than nothing? If you reap the container when that process dies, you can’t race for the same PID, at least. I dunno
My understanding is this is exactly how Vercel works. The users hadn’t checked the “don’t ever reveal, even to me” box next to the sensitive values. If they had, the attacker would only have been able to see the names of the variables and not their values.
It looks like tricolon is about specifically three parallel elements, while staccato is about short consecutive sentences, so staccato would be the appropriate name here.
It would be OK, but the point I'm raising is that the Grammarly-like design encourages the user to resolve everything it highlights, to make the text look uniform and spotless.
Don't attach your pride to how well a product you work on is received. You can still take pride in improving a poorly received product, or even in just trying.
That didn't use to be the case. In the US many laws were approved in the 1930s that forced businesses to keep stakeholders in mind, not just shareholders. That led the US to become the global powerhouse it became, and its middle class to boom. Then in the late 1970s came deregulation, and those laws were all reversed, resulting in the new two-class system Americans are learning to hate, a new robber barons era very reminiscent of the previous one.
Too bad most everyone is lost in the artificially engineered "culture war" to notice they have a common enemy, one who benefits from the proles fighting each other rather than uniting against them.
The syntax makes perfect sense when you understand the semantics of the language.
Out of curiosity, have you read the jq manpage? The first 500 words explain more or less the entire language and how it works. Not the syntax or the functions, but what the language itself is/does. The rest follows fairly easily from that.
For better or worse, Claude is my intuitive interface to jq. I don't use it frequently, and before I would have to look up the commands every time, and slowly iterate it down to what I needed.
Steam runtime already gives developers a single target rather than having to support different distros individually.
If Steam Deck, the new Steam Machine etc take a significant part of market share, I think it will be more enticing for game developer to release a native version for Linux. Providing a native version should still be more robust and performant.
reply