Show HN: Lockenv – Simple encrypted secrets storage for Git

Posted by shoemann 7 days ago

Show HN: Lockenv – Simple encrypted secrets storage for Git(github.com)

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!

105 points | 34 commentspage 2

mrinterweb 7 days ago|

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.

sureglymop 7 days ago||

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

lucyjojo 6 days ago|

it strikes me as reasonable for 1-10 people teams (well, small businesses).

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.

sureglymop 6 days ago||

Consider even just the chance that at some later point you want to remove the secrets. Now you have to rewrite history and also force that on all contributors.

lucyjojo 6 days ago||

at that point keep them in there, quit using the "secrets in repo" strategy from now on and rotate all your secrets in your new vault.

you also have the option to cut a new repo. it's a small team, you don't have behemoth inertia.

(secrets in repo if your code is open-sourced is indeed not a good idea at any scale. it's also a bad idea if your secrets cannot be easily meaningfully rotated, like putting your social security number in a secret.)

chrisweekly 7 days ago||

Committing the vault to git gives me the heebie-jeebies. (Not that I have a better solution with anything like this convenience.)

sshine 7 days ago|

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.

akabalanza 7 days ago||

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

rcarmo 7 days ago|

I use a Makefile target with GPG :)