More seriously though, you're supposed to use separate vaults (with the same keys, where "keys" is the name of the secrets, not the decryption keys) for testing/staging/production, e.g. perhaps secrets.{testing,production,staging}.json and the same secrets.{testing,production,staging}.key for the decryption keys, and store both the username and password in them (after all, it's just an encrypted, glorified KV store) so that you don't have to hard-code any usernames and conditionally load them based on the environment in your code (so db:username is one "secret" and db:password is another (actual) secret).

The secrets vaults (the secrets.json files) are non-sensitive and can be versioned and pushed to your server the same way you push the binaries. Now how you move the secrets to the server is up to you. You could do it the old-fashioned way and just have it as an environment variable, in which case even when your env vars leak at least you haven't leaked your api keys, only the key to decrypt them (which you'd then rotate), but that's not a recommended option. Ideally you'd instead use whatever secure channel you use to init/stage the servers to begin with to transfer the secure key files - the key files are generally immutable, even as the secrets change, so you only have to do this once (ideally via a high-friction, high-auth mechanism, for most people not at FAANG scale, probably manually).

You can also use whatever additional layer of abstraction on top of the symmetric SecureStore decryption key you like. For example, you could asymmetrically encrypt the keyfiles and then each host would decrypt it with its own private key, or have a secrets side channel that's just used to obtain the static decryption key over the local network, or use your operating system's encryption facilities to transmit it, whatever works for you at whatever point on the complexity/security curve you desire.

(These are all just options, none are official recommendations.)

I didn’t get a chance to do a write up but the golang port is here: https://github.com/neosmart/securestore-go

The approach to crypto is very different, we went with what’s very well understood and very well supported on all platforms with little or no dependencies (eg we can use web crypto in JS frontend or backend with no external libs or crypto JS library nonsense).

The original .NET and Rust code is from over a decade ago and carefully architected (well before vibecoding was a thing), the secrets are stored in a human readable (json) vault that can be embedded in your binaries or distributed alongside them and be decrypted with either password-based or key-based decryption (or both).

The rust repo has the most info: https://github.com/neosmart/securestore-rs

I just migrated to MS artifact signing and, thank the lord, had an actually easier time getting verified than I did with the Sectigo and Comodo in the past. I’m sure I’m not representative of anyone else’s experience but having already had a developer account (with a different email and without an Azure account!) that I had already been using for the Microsoft Store might have helped, as well as the fact that I had a well-established business history (I’ve heard businesses younger than 3 years can’t get verified??), but reading all the comments here makes me very uneasy about the future.

It’s good to know the HSM route isn’t a complete non-starter. The main reason I panned it is that when I started looking into this I found that a number of companies that had previously offered the HSM route had done a bait and switch and were now keeping custody unless you were big enterprise (meaning willing to put up with 10k/yr fees). I did find a few that would allow OSS devs to sign their work, but read horror stories on Reddit and elsewhere about their freezing the account and issuing no refunds if you ask them to issue the cert in the name of your LLC or corporation instead of with your personal name (which I expressly did not want). Also, they actually were more expensive than Azure artifact signing even after the HSM cost was taken out.

Anyway, even if you could get your own cert it would be same thing: MS could revoke or blacklist your indicate cert (though usually the grounds for doing so are much less shaky than your account being suspended for vague “tos violations”)

No one is calling an executive meeting to discuss banning an OSS dev’s account.

Ideally they'd always carry an "AI-generated" flag (in the db and in the frontend) until manually reviewed (or never) by a human. If anything, this is actually in AI proponent's favor as it would let you periodically regenerate or cross-validate (a subset of) the AI contributions some years down the line when newer and better models are released!

Comments URL: https://news.ycombinator.com/item?id=47640852

Points: 21

# Comments: 1