[HN Gopher] Show HN: Lockenv - Simple encrypted secrets storage ...
___________________________________________________________________
Show HN: Lockenv - Simple encrypted secrets storage for Git
Hi! 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!
Author : shoemann
Score : 91 points
Date : 2025-12-08 07:36 UTC (15 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rcarmo wrote:
| I use a Makefile target with GPG :)
| jillesvangurp wrote:
| Sounds useful. We do similar things with encrypted properties
| files. Also, things like Ansible come with ansible vault. If you
| use Github, you can use Github secrets of course. And
| AWS/GCP/etc. tend to have secret stores.
|
| 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.
| shoemann wrote:
| Absolutely agree. That is exactly why I made this tool - my
| projects usually don't have ansible, github, aws and other
| external dependencies, or have different sets of such
| dependencies, and teams are too small to use something
| enterprise level.
| crote wrote:
| > 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.
|
| 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.
| pverheggen wrote:
| Regarding the sticky note problem, this can be mitigated with
| separate vault credentials for production. That way you can
| limit prod secrets to a much smaller group, and if you wanted
| to rotate when someone leaves, you'd have to do it much less
| often.
| akabalanza wrote:
| That looks amazing, thanks for sharing!
|
| I have a git-based sync tool for my dotenv files. Maybe I can
| store my ssh keys, too
| Barathkanna wrote:
| This 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 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.
| 8cvor6j844qw_d6 wrote:
| > stop pasting secrets into Slack
|
| You got me interested. I've seen sharing of API keys via
| Discords in hackathons.
| mhitza wrote:
| 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/t
| oolbox/blob/main/scripts/encrypt-...
| encrypt-for github_username file
| cl3misch wrote:
| 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...
| submain wrote:
| This is great! Coincidentally, I just started replacing my
| collection of bespoke security bash scripts with an app like
| yours. WIP here: https://github.com/leolimasa/age-vault
|
| We all keep reinventing the same thing :)
| steffoz wrote:
| Very similar to a tool I built about a year ago! We've been using
| it with our 6-person team, and it's been working great. It uses a
| shared keyring.json to manage public keys, so we don't have to
| duplicate the same keys across every repo.
|
| https://github.com/stefanoverna/kavo
|
| It's built on top of age for encryption
| (https://github.com/FiloSottile/age).
| chrisweekly wrote:
| Committing the vault to git gives me the heebie-jeebies. (Not
| that I have a better solution with anything like this
| convenience.)
| sshine wrote:
| 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.
| andreineculau wrote:
| I 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.
| mbreese wrote:
| Secrets 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...)
| SomeUserName432 wrote:
| > or 1Password vaults are harder to work with
|
| https://1password.com/blog/1password-environments-env-files-...
| eddyg wrote:
| I've been using git-crypt(1) 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.
|
| (1)https://github.com/AGWA/git-crypt
| peanut-walrus wrote:
| The 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.
| nothrabannosir wrote:
| Agreed with 1 and 3, just a tip re 2 though: sops encodes json
| and yaml semantically, key names of objects are preserved. Iow
| you can see which key changed.
|
| Whether that is a feature or a metadata leak is up to the
| beholder :)
| jamietanna wrote:
| Re 2 you can implement a custom Git diff tool, and so (with the
| encryption key) see what's changed, straight from `git diff`
| e12e wrote:
| This looks nice, but I think I lean towards fnox (by the author
| of mise) - because of the flexibility and support for external
| storage:
|
| https://github.com/jdx/fnox
| sureglymop wrote:
| I 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).
| mrinterweb wrote:
| This reminds me of how rails manages encrypted credentials.
| https://guides.rubyonrails.org/security.html#custom-credenti....
| The big differences, this is portable and sets values as session
| env vars instead of application vars.
| madeforhnyo wrote:
| Being a node dev - by necessity, I've settled on dotenvx [0] for
| committing encrypted .env files.
|
| [0] https://dotenvx.com/
| n31l wrote:
| Agreed, and it's nice and easy for anyone already using `.env`
| files, although the private key used to decrypt the dotenvx
| key-values is itself a secret.
| hersko wrote:
| Yeah i don't understand this. You still need to secure your
| .env.keys file same as you would be doing with a standard
| .env. Is the benefit just that you can track it with git?
| kevlened wrote:
| Standard .env is unencrypted, while a dotenvx .env file has
| plaintext keys and encrypted values. Anyone with access to
| the repo would also need the DOTENVX_PRIVATE_KEY variable
| to decrypt the env file.
|
| 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.
___________________________________________________________________
(page generated 2025-12-08 23:01 UTC)