Navigate to… Terms and acronyms What this is, and how to read it Passwords for programs, and why we refuse them Envelope encryption: the key idea The mailbox trick: public-key encryption Signing is not encrypting Locks and keys: symmetric encryption Who are you defending against? The two questions every secrets system must answer What a secret is Why secrets leak The cast of characters Where your private key actually lives What we deliberately do not have The bet: the server should be powerless How the layers stack Asserted vs attested: two very different promises Two modes, one format The uncomfortable truth we start from What the audit log can tell you phase 3 Bus factor When two people write at the same time The weekly checkup Fingerprints, and how trust is kept over time Giving someone access You lost your key. Now what? Reading a secret Taking access away The three rotations Versions, and how a secret changes without breaking anything Writing a secret Backups and drills Create an organization (serverless) Config reference Install Onboard a machine (CI, a service) Turn on the server (optional) phase 3 Onboard a teammate Asserted custody cannot be enforced We cannot protect you from your own machine Metadata leaks even though contents do not Stolen ciphertext can be attacked forever Cloud misconfiguration is outside our reach Revocation is not retroactive, and serverless mode has no read log You have to trust the client itself Command cheat sheet Glossary Config reference¶
Client configuration lives in ~/.config/secretsmgr/config.toml, one section per organization, so you can belong to several:
[org.acme]
mode = "serverless" # or "server"
repo = "git@git.example.com:acme/secrets.git"
server = "" # https://… when mode = "server"
root_fingerprint = "correct-horse-battery-staple-…"
principal = "priya"
custody = "file" # file | fido2 | kms | ambient
key_path = "~/.config/secretsmgr/acme.key"
cache_ttl = "5m" # in-memory only; 0 disables
Select an organization with --org acme or SECRETSMGR_ORG=acme. Each organization is a separate trust boundary with its own root fingerprint; we recommend a separate keypair for each, so a problem in one never implicates another.