3 ms·

Committing the vault to git gives me the heebie-jeebies. (Not that I have a better solution with anything like this convenience.)

• sshine 11mo ago
  The way I think about it is: - Maintaining stateful secrets at rest gives me the heebie-jeebies. - The tools shouldn't let me shoot myself in the foot. - The tools should ideally not have such a high learning curve that I won't actually use them. You can put your secrets in a separate repository and not think of them as the same kind of repository you'd publish. Like... I wouldn't put a git-crypt'ed / sops-nix'ed repository online, simply because I don't like the idea that now anyone needs is brute-force; I know quantum computers aren't there yet wrt. brute-forcing stuff made by random people like me, but even hypothetically having this attack vector open, I don't like it. So there's only two good solutions: - You put secrets in a (hashicorp-style) vault that only decrypts temporarily in memory. - You put secrets in an encrypted database with only safe tool integration. The things I don't like about git-based secrets management: 1. You might mix your secrets into projects and then later someone else might release that (against your current interest) 2. The solutions I've seen (sops-nix, agenix, secrix, etc.) are hard to set up and even harder to onboard people on When something's hard to set up, you might make a mistake or skip some concept. Well-done secrets management that isn't based on a service like AWS Secrets og GitHub Secrets should be much, much easier. I like the idea of how easy this is. Now, if it would just be best practice in every possible way at the same time. The (admittedly well-known) problem with lockenv is that you can't revoke access once a password is known. It's a big ask.