Gopass brings git and GPG discipline to your team’s secrets

Help Net Security recently profiled Gopass, an open-source command-line password manager built on two ancient, trustworthy ideas: GPG for encryption and git for history. On paper that sounds like a step backward from the polished vaults most teams use. For human logins, it is — keep your SSO-backed password manager. But for the credentials your infrastructure actually uses, Gopass fills a gap the pretty tools have quietly ignored for a decade.

The gap between vaults and terminals

GUI vaults are superb at one thing: serving browsers and phones, where a human clicks a field and wants a password filled in. They’re clumsy at serving the consumers that matter in ops. Your CI runner doesn’t have a browser extension. Your Ansible playbook isn’t going to pop an unlock dialog. Your deploy script can’t copy-paste from your phone. So machine credentials — API tokens, service account keys, SSH keys for automation, the vault password itself — end up somewhere worse: a wiki page, a Slack DM, a plain-text file on a share. That’s the incident waiting to happen.

Gopass (gopass.pw, a drop-in replacement for the classic pass) meets the terminal where it already lives. Secrets are GPG-encrypted files in a directory tree. Sync is git. Retrieval is gopass show work/aws-access-key. Generation is gopass generate work/github-token 32, which copies to your clipboard and — more importantly — means strong credentials never transit chat or a text file on their way into existence. If GPG’s key management annoys you, there are alternative backends like age.

The team model is GPG recipients and git history

Here’s what makes it a team manager rather than a personal toy. Every secret is encrypted to a set of GPG recipients — that’s your access control. Add a teammate’s key to a store, and they can decrypt everything in it; remove it, and (going forward) they can’t. Sub-stores let you mount separate trees, so prod/ is encrypted to a different recipient set than dev/, and the intern’s laptop simply isn’t a recipient of production. The whole thing syncs over a git remote you already run on infrastructure you already trust.

And the audit log? It’s git log. Who added that token, when, and exactly what changed — diffable, greppable, and exportable without asking a vendor for an audit add-on. For a small business that can’t afford a secrets platform, this is the compliance story: versioned, attributable, boring.

The honest costs

Because every “just use git and GPG” pitch owes you the downside:

• The key ceremony is real. Every team member needs a GPG key pair, and you need to actually think about revocation and expiry. Most teams discover their key hygiene the hard way here.
• Lose the private key, lose the secrets. Encrypted to recipients means exactly that. Back up private keys properly — offline, durable — or don’t back them up at all and accept the risk knowingly. “It’s on my laptop” is neither.
• Non-technical staff get nothing. There’s no pleasant phone app moment here. Don’t force it; Gopass complements your human-facing vault, it doesn’t replace it.
• Browser integration is an add-on, not magic. gopass-bridge exists for Firefox and Chrome, and git-credential-gopass wires it into pushes — but expect to configure them, not click them.

How I’d roll it out without a big bang

Start with a machine-credentials store, not with people’s logins. API tokens, service accounts, automation SSH keys — the stuff currently smeared across runbooks. Host the store’s git remote on infrastructure you already operate. Generate credentials through gopass generate from day one so they never exist anywhere else. Wire the git credential helper so daily pushes stop prompting. Leave human logins in whatever vault your team actually likes. Then — before anyone needs it — write the key-recovery run down and rehearse it once. The first time you test key recovery should not be the time it matters.

The feature isn’t the encryption; every vault has that. It’s that your secrets store now works like your code: versioned, reviewable, diffable, and auditable with tools you already know. Secrets management doesn’t need to be exciting. Exciting is what you’re trying to avoid.