babawere

Both, honestly. Fun and production intent. But `production` here is very specific, embedded in a single Go binary, a single *.db not a CLI tool (the cli you see there is just for inspection) for developer or CI.

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.

The first bug has been confirmed however The second `vulnerability` would only be exploitable if an attacker could also break SHA-256 preimage resistance to forge valid checksums ??? correct me if am wrong

Thanks for sharing this. secret looks really well thought out, the three-layer key hierarchy is impressive. And using `age` is a solid choice. once considered it.

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

Thanks for the look. On the verification hash, you're right, SHA256 would work there. Argon2id was overkill, I agree 100%.

The crash-safe WAL is the part I'm most nervous about too. That's exactly why I posted this. I want eyes on the rotation logic specifically.

And yeah, single bbolt db is a limitation. I could have used pebble or any other, but trade-off for simplicity (a single *.db). A true WAL will need external file. The storage is pluggable though also open to improvement.

Still very young.

So have been told. Will definitely look for a better name

thanks for the update ... will definitely look for a better name

Honestly… the initial use case is to hide certs from the file system and secrets from the environment. However, this can be extended.

The primary issue has been not being able to manage an encrypted storage system… the main goal is to have something that can be audited, not just secured.

yes 100% ... embeded

Definitely … agents cannot access your password unless you save it to the environment too. However it's better to use resolvers ... depending on your use case

not when you need an audit system

I was thinking its better to be boring-correct :)

Even when you have a proper function and use AI for auto documentation, it silently changes it (insane) … I will defiantly fix this.

Can you please explain in details?