Posted by shoemann 7 days ago
I got tired of setting up tools I can't explain to a team in a few words like sops or git-crypt, just to store few files with environment variables or secrets, so I built lockenv as a simple alternative.
It's basically a password-protected vault file you commit to git. No gpg keys, no cloud, just lockenv init, set a password, and lock/unlock the secrets.
This tool integrates with OS keyring, so you're not typing passwords constantly. Should work on Mac/Linux/Windows, but I tested it only on linux so far.
I am not trying to replace any mature / robust solution, just making small tool for simple cases, where I want to stop sharing secrets via slack.
Feel free to try, thank you!
- Sharing encryption key for all team members. You need to be able to remove/add people with access. Only way is to rotate the key and only let the current set of people know about the new one.
- Version control is pointless, you just see that the vault changed, no hint as to what was actually updated in the vault.
- Unless you are really careful, just one time forgetting to encrypt the vault when committing changes means you need to rotate all your secrets.
Whether that is a feature or a metadata leak is up to the beholder :)
> 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.
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.
- using a third party tool to read and store credentials is an attack vector itself.
But storing secrets in the same git repository just seems off to me. I don't like the idea of keeping the secrets (even in encrypted form) with the code I'm deploying.
There should be a better balance somewhere, but I'm not sure this is quite it for me. Shared keepass files (not in git) or 1Password vaults are harder to work with, but I think lean more towards the secure side at the expense of a bit of usability. (Depending on the team, OSs, etc...)
https://1password.com/blog/1password-environments-env-files-...
https://github.com/stefanoverna/kavo
It’s built on top of age for encryption (https://github.com/FiloSottile/age).
The challenge with this solution is of course managing who has access and dealing with people leaving your team and no longer being trusted. Even if you still like them personally, just because they are outside your team would require you to change any credentials they might have.
In our case, our team is small and I simply ignore this problem. So, we have a keepass file with shared secrets and repositories with encrypted properties files and a master password in this keepass file. Mostly, it's just me handling the password. It also gets configured as a Github secret on repositories for CI and deployment jobs. It works. But I'm aware of the limitations.
This is an area where there are lots of tools but not a whole lot of standardized ones or good practices for using them. It's one of those things that acts as a magnet for enterprise complexity. Tools like this tend to become very unwieldy because of this. Which is why people keep reinventing them.
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.
We all keep reinventing the same thing :)
One key deployed to your hosts means adding new secrets doesn't take operations effort. Also, the process uses a public/private key pair, so adding a new variable doesn't expose existing variables.
I like the OS keyring integration too,removes a lot of friction. Curious how it behaves in multi-machine workflows and whether you plan to add any guardrails around accidental plaintext commits, since that’s usually where lightweight tools get tripped up.
You got me interested. I've seen sharing of API keys via Discords in hackathons.
Here's a small shell script I use https://github.com/mhitza/toolbox/blob/main/scripts/encrypt-...
encrypt-for github_username file> Keep in mind that people might not protect SSH keys long-term, since they are revokable when used only for authentication, and that SSH keys held on YubiKeys can't be used to decrypt files.
https://github.com/FiloSottile/age?tab=readme-ov-file#encryp...