21–30 of 37 posts
Genuine question: what's your thread model? Vault gives time limited Tokens with Network Boundary. Instead of Keeper, i would just use age: # write echo "my secret" | age -r > secret.age # read age -d -i key.txt secret.age
This is an age+filesystem secrets manager that I made that is basically what you wrote, but with more organization.
I have a similar one called “secret”, also in Go, that is more CLI-focused and uses the filesystem as database. https://git.eeqj.de/sneak/secret
Different trade-offs though, Keeper is library first embedded. secret does per version keys with symlink switching - nice, Keeper does per-bucket DEK isolation + audit chains. Both solve "encrypted local storage" but for different workflows.
I'll definitely be looking through your code for ideas
Hey I ran this request through my AI harness (beigeboxoss.com), first with a smaller local model and then validated with Trinity Large via OR. https://github.com/agberohq/keeper/issues/2 -- YMMV but wanted something to do with my coffee, thanks!
Genuine question: what's your thread model? Vault gives time limited Tokens with Network Boundary. Instead of Keeper, i would just use age: # write echo "my secret" | age -r > secret.age # read age -d -i key.txt secret.age
not when you need an audit system
From a project perspective, is this for fun or is it meant to be a production solution? If the latter, what problem(s) are you trying to solve that established solutions like fnox don't? https://github.com/jdx/fnox (I'm an fnox user who's unfamiliar with this space, and am curious what your critiques would be.)
The problem fnox solves is great, unified access to secrets across dev, CI, prod with cloud backends. That's a different layer of the stack.
Keeper solves a lower-level problem: you have a Go process (a load balancer, a control plane, a daemon) that needs to store secrets inside its own database not in a separate file, not in a cloud vault, not in env vars. Secrets that need per bucket isolation, audit trails, and crash-safe rotation.
Here is my thinking :
- fnox = how your CLI and deploy scripts get secrets
- Keeper = how your running binary stores secrets at rest
Different problems, Could I build Keeper on top of fnox? Probably. But then I'd have a file on disk with secrets that fnox manages which is exactly the problem I wanted to eliminate.
I didn’t get a chance to do a write up but the golang port is here: https://github.com/neosmart/securestore-go
The approach to crypto is very different, we went with what’s very well understood and very well supported on all platforms with little or no dependencies (eg we can use web crypto in JS frontend or backend with no external libs or crypto JS library nonsense).
The original .NET and Rust code is from over a decade ago and carefully architected (well before vibecoding was a thing), the secrets are stored in a human readable (json) vault that can be embedded in your binaries or distributed alongside them and be decrypted with either password-based or key-based decryption (or both).
The rust repo has the most info: https://github.com/neosmart/securestore-rs
We actually just ported SecureStore to go, it’s sort of like this but with cross platform clis and intended to also allow sharing secrets across services and languages, in a secure and embedded fashion! It’s available in rust, php, .net, JS/TS, Python, and golang and easy to port to others. I didn’t get a chance to do a write up but the golang port is here: https://github.com/neosmart/securestore-go The approach to c…
The JSON vault + cross-language portability is nice too, especially if you’re embedding secrets across services without tying yourself to one runtime. Curious how you handle key management at scale though — that’s usually where these systems get tricky more than the crypto itself.