At least it's a clearly exposed problem: everyone who has ever cloned the repo has a copy of your secrets.

With software like 1Password it is way too easy to blindly rely on built-in permission management. People implicitly assume that removing a person's 1Password access means they can no longer rely the underlying resource - but in practice they could've copied the secret onto a sticky note at any time, and it's not safe until you've rotated the secret!

With shared user accounts there's at least usually the possibility of using 2FA - but that's not exactly going to work with things like deployment tokens intended for automated use...

Of course in an ideal world we wouldn't have those kinds of secrets and we'd all be using short-lived tightly-scoped service accounts - but we don't live in an ideal world.

You got me interested. I've seen sharing of API keys via Discords in hackathons.

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

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.

  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

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.

https://1password.com/blog/1password-environments-env-files-...

Whether that is a feature or a metadata leak is up to the beholder :)

edit: wrong way to phrase I think. What I mean to say is, have a message key to encrypt the body, but then rotate that when team membership changes, and "let them know" by updating a header that has the new message key encrypted using a key derived using each current member's public key.

> Sharing encryption key for all team members

you're enrolling a particular users public/key and encrypting a symmetric key using their public key, not generating a single encryption key which you distribute. You can roll the underlying encryption key at any time and git-crypt will work transparently for all users since they get the new symmetric key when they pull (encrypted with their asymmetric key).

> Version control is pointless

git-crypt solves this for local diff operations. for anything web-based like git{hub,lab,tea,coffee} it still sucks.

> - Unless you are really careful, just one time forgetting to encrypt the vault when committing changes means you need to rotate all your secrets.

With git-crypt, if you have gitattributes set correctly (to include a file) and git-crypt is not working correctly or can't encrypt things, it will fail to commit so no risk there.

You can, of course, put secrets in files which you don't chose to encrypt. That is, I suppose, a risk of any solution regardless of in-repo vs out-of-repo encryption.

- using a third party tool to read and store credentials is an attack vector itself.

the real problems/risks only creep up for mid to big size businesses, which i don't think the tool is concerned with.

from my understanding the big problems would be:

- auditing/leaking risks that come with bigger headcount/turnover - bad uncontrolled use & problems with policy - operational inertia when problems happen

these are not real for most (healthy) small teams.

the really touchy problem is decryption key management and running state management.