Hi HN,
I built AxKeyStore, an open-source CLI tool for managing secrets that uses your own private GitHub repository as encrypted storage.
The idea is simple: → All encryption happens locally. → Secrets are stored as encrypted blobs in your private repo. → GitHub is treated as untrusted storage. → No plaintext secrets ever leave your machine. → No plaintext secrets are stored on disk.
Most secret managers either require a hosted backend, a self-hosted server, or trusting a SaaS provider. I wanted something that: → Requires zero infrastructure → Uses tooling developers already have → Keeps the threat model simple
AxKeyStore uses a layered approach to security: → Secrets are encrypted with a Remote Master Key (RMK). → The RMK is encrypted with your master password and stored in the repo. → A Local Master Key (LMK) encrypts your local GitHub token and repo config. → The LMK itself is encrypted using Argon2id-derived keys from your master password. → Encryption uses XChaCha20-Poly1305 (AEAD).
GitHub only sees encrypted binary blobs. Even if someone compromises your repository, they still need your master password to decrypt anything.
Why GitHub? Because it gives: → Private repositories → Version history (commit log as audit trail) → Access control → Free storage → Global availability
Instead of building a backend, I’m leveraging an existing, reliable system - but cryptographically isolating it.
Features → Simple CLI workflow → Hierarchical categories (e.g., cloud/aws/prod) → Version history per secret (via commits) → Retrieve specific versions by SHA → Multi-profile support (separate vaults) → Transactional master password reset → Secure random secret generation
Tech → Written in Rust. Uses tokio, clap, argon2, and chacha20poly1305. → There are unit and integration tests (including mocked GitHub API interactions). → Open source - MIT licensed.
I’d appreciate feedback on: → The threat model - what am I missing? → Whether GitHub as encrypted blob storage is a bad assumption → UX improvements for CLI-based secret workflows → Any crypto or key-handling concerns
I’m especially interested in critique from people who’ve built or audited secret management systems.
Thanks.