Comment by chrisweekly

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.