Hey there, fellow and future Ubuntu contributors!
Let me open with a slightly uncomfortable question: where, right now, is the private key that represents you in the Ubuntu project? The one that signs your uploads to the Archive, vouches for your identity, and lets people send you confidential mail?
For many of us the honest answer, for many years, has been: “somewhere under ~/.gnupg, on the same disk as everything else.” And that should make you at least a little nervous.
It doesn’t really matter who exactly you are worried about — an actual attacker who got onto your machine, the company-managed laptop that quietly runs something as root, or the friendly AI coding agent you forgot to keep on a tight leash. None of them should be able to impersonate you just because your secret has been lying around on disk, readable, waiting.
This article is about fixing exactly that. After years of “you really should use a hardware key” advice without a clear, agreed path to actually follow, the Ubuntu project now has a documented what, why and how for a hardware-backed PGP setup.
Let me walk you through it.
| Question | Short answer | Where to go deep |
|---|---|---|
| Why bother? | Your PGP key is your identity in Ubuntu — and therefore a juicy target | PGP key recommendations |
| What to aim for | Private key material off disk, on a hardware key you physically hold | PGP key recommendations |
| How to get there | A step-by-step setup with an offline primary key and subkeys on hardware | Set up and manage PGP keys |
“Why” your PGP key is worth all this fuss
The Ubuntu project leans on PGP keys for some genuinely critical jobs: they authenticate you as an individual, they sign your uploads to the Archive and to PPAs. Using them for encryption further makes confidential communication possible. That is a lot of trust riding on one little blob of bytes — which is precisely what makes it such a high-value target.
Here is the part worth internalizing: that key doesn’t identify a role, an Ubuntu team, or your employer. It identifies you, the human. The goal is for you to be in sole control of it — sole knowledge of the passphrase, sole control of the device it lives on. A file on disk can’t give you that, because anything (or anyone) that can read the file effectively might become you.
This is also why “just use a strong passphrase” stopped being a satisfying answer on its own.
A passphrase is a good foundational layer, but raw compute keeps getting cheaper, and a passphrase still assumes the encrypted key never leaves your control. The much stronger property is to make sure the secret material simply isn’t there to steal in the first place.
“What” to do: keep the secret off disk
The recommendation — now written down as actual project guidance rather than tribal knowledge — boils down to a handful of practices that reinforce each other:
- Use a hardware security key. A device with a secure element performs the PGP operation on the chip; the private key never gets handed to your possibly-compromised laptop.
- Require presence and a PIN. Configure touch (user-presence) and PIN so that no background process can quietly sign on your behalf — you have to physically tap the key. This single setting defangs a whole class of “malware silently signs things” attacks.
- Keep an encrypted, offline primary key. The long-lived primary “certify” key is your root of trust. It lives locked away, offline and encrypted, and only comes out on rare occasions (like minting new subkeys). It never needs to be comfortable or quick to reach.
- Carry two hardware keys, not one. Configure two devices so a lost, broken, or forgotten key doesn’t lock you out — particularly painful if it happens while you’re travelling. Keep them apart, so the same spilled coffee or stolen bag can’t take out both.
- Set expiration dates and revisit them. Short-ish expirations (say 1–2 years), ideally offset between your two keys by a few months so they never expire on the same day, act as a “dead man’s switch” and give you a natural checkpoint to re-audit your setup.
Nicely, hardware keys also let you separate owning the computer from owning the identity. The laptop can belong to your employer; the key — and the “you” it represents — stays yours.
A fair word of caution, because I like to keep my skepticism handy: no scheme is risk-free.
Cryptanalysis advances, implementations have bugs, and hardware keys aren’t accessible to everyone. Hardware-backed keys are simply the best balance of security and day-to-day comfort we can recommend today.
“How” to get to a setup you can actually follow
The “what” and “why” landed first, as policy. The piece that was missing — and the reason this whole topic stayed stuck in “someday” for so long — was a concrete, opinionated, end-to-end how-to. There were always plenty of GPG guides out there, but none of them spelled out the steps, scope and intent aimed specifically at working as an Ubuntu developer. So we started with the scribble notes of a few early adopters and then ran a team or two through the process, sanded down the rough edges, and the result is now Set up and manage PGP keys.
I won’t paste the whole thing here — that’s what the guide is for — but the shape of the target setup is worth seeing at a glance:
- One long-term primary key (C) used only to certify subkeys, generated offline and then locked away.
- Signing subkeys (S) — one per hardware key — used for the actual day-to-day signing.
- One encryption subkey (E) present on each hardware key, so you can decrypt with whichever one is in your pocket.
- Subkeys live only on the hardware — not on disk.
- A documented fallback plan for when a key is lost, expires, or is compromised.
Think of it like a bank vault: the master that can cut new keys stays in the vault (your offline primary key), while the working keys ride on a physical keyring that won’t turn without your physical touch.
The guide walks you through generating the primary key (ideally from an ephemeral Ubuntu Live session so nothing lingers on disk), adding subkeys, moving them onto the hardware, and then — the step people are tempted to skip and absolutely must not — backing everything
up offline and encrypted before wiping the secret material from your machine.
It also covers the day-2 reality: importing onto a new laptop (spoiler: you mostly just plug the key in), extending expiration dates, and reacting fast if a subkey is ever compromised.
And yes, it ends where it matters most for us — signed git commits and signed Launchpad and Ubuntu uploads.
If you’ve read past Gazette issues you’ll know I have a soft spot for the quiet, reliable and foundational work — this security topic slots right in next to the time and trust topics from Issue 5.
Protecting your identity is just another circle of friends worth keeping safe.
There’s more coming: protecting the other doors too
Here’s an honest gap I want to name out loud, because the policy itself does.
Signing uploads is not your only privileged interaction with the Archive. You also talk to the Launchpad API — through launchpadlib, lp-shell, archive tooling and the like — and today that authentication typically sits in a file or a keyring that’s unlocked the moment you log in. From an attacker’s point of view (and this is exactly the lesson from recent supply-chain credential-theft sprees), that’s about as good as plaintext. We’d be locking the front door while leaving a window open.
So while I won’t get into design details — this is genuinely being worked on — I want you to know the direction, because it’s going to be great:
- Hardware-bound API tokens. The same idea you just set up for signing, extended to Launchpad API access: tokens that do not reside on disk and are useless without a tap on your hardware key.
- Scoped access tokens. The ability to hand a script or a bot a token that carries only the permissions it needs instead of everything you can do. Least privilege, finally, for Launchpad — so the code you run (audited or not) can’t quietly act with your full powers.
Put those two together and the picture gets genuinely exciting: your identity protected by hardware, and your automation reduced to the narrow slice of access it actually requires. I’ll come back to these once they’re real enough to play with.
Your next step
The recommendations are voluntary — but I’d beg you for your identities sake it is worth to look at.
Grab a key (or two), block out an afternoon, and follow the how-to. Read the why first if, like me, you prefer to understand a thing before you trust it. And if you hit a rough edge the early adopters didn’t, say so by contributing to the ever growing Ubuntu Project Documentation — that’s how this guidance got good in the first place, and how it keeps getting better.
Keep your secrets safe and enjoy a better day, everyone!