Committing the vault to git gives me the heebie-jeebies. (Not that I have a better solution with anything like this convenience.)
Show HN: Lockenv – Simple encrypted secrets storage for Git
11–20 of 35 posts
Re: Show HN: Lockenv – Simple encrypted secrets storage for Git
#12Committing the vault to git gives me the heebie-jeebies. (Not that I have a better solution with anything like this convenience.)
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.
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.
Re: Show HN: Lockenv – Simple encrypted secrets storage for Git
#13This actually looks handy for the “small team with a couple of env files” use case. Most secret-management tools are great once you’re at scale, but trying to explain sops or git-crypt to a team that just wants to stop pasting secrets into Slack is… not fun. A simple password-protected vault committed to git is a reasonable middle ground. I like the OS keyring integration too,removes a lot of friction. Curious how it…
> stop pasting secrets into Slack You got me interested. I've seen sharing of API keys via Discords in hackathons.
You can use the age tool to encrypt secrets based on ssh public keys.
Here's a small shell script I use https://github.com/mhitza/toolbox/blob/main/scripts/encrypt-...
encrypt-for github_username fileRe: Show HN: Lockenv – Simple encrypted secrets storage for Git
#14I understand the simplicity angle. https://github.com/elasticdog/transcrypt has been around for a long time and strikes that balance very well in my opinion. And it's just a bash script that can also be committed so the git repo is atomic.
Re: Show HN: Lockenv – Simple encrypted secrets storage for Git
#15Secrets management is hard. And proper secret sharing setups meant for larger groups are quite unwieldy to work with with smaller groups. Well, they are hard to work with for all sizes of groups, but it seems particularly overkill for small groups. So I see why you'd want to do this. I also kinda like the idea of just encrypting/decrypting .env files. It's a pretty clean design.
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...)
Re: Show HN: Lockenv – Simple encrypted secrets storage for Git
#16I’ve been using git-crypt⁽¹⁾ which is transparent (you put the patterns you want to encrypt in .gitattributes) and lets you use GPG keys or symmetric keys. And it's been around for quite a while.
Re: Show HN: Lockenv – Simple encrypted secrets storage for Git
#17The main problems with these kinds of in-repo vault solutions:
- 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.
Re: Show HN: Lockenv – Simple encrypted secrets storage for Git
#18This looks nice, but I think I lean towards fnox (by the author of mise) - because of the flexibility and support for external storage:
Re: Show HN: Lockenv – Simple encrypted secrets storage for Git
#19I understand the thought but my honest advice is: do not commit secrets to git, even if they are encrypted.
Secrets are not configuration, they are state (and I would say, an even stricter form of state that should ideally only exist at runtime in memory).
Re: Show HN: Lockenv – Simple encrypted secrets storage for Git
#20Earlier quoted context omitted.
> stop pasting secrets into Slack You got me interested. I've seen sharing of API keys via Discords in hackathons.
You can use the age tool to encrypt secrets based on ssh public keys. Here's a small shell script I use https://github.com/mhitza/toolbox/blob/main/scripts/encrypt-... encrypt-for github_username file
That's handy and obviously a major security increase compared to sharing on Discord, but I feel compelled to quote the age README:
> 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...