That NO_PUBKEY error? It’s telling you your package manager’s trust is broken.

Technical Briefing | 11/3/2026

You’ve seen it: a routine ‘apt update’ suddenly spews a bunch of red text about ‘NO_PUBKEY’. Most folks quickly Google the error, copy-paste a command, and move on. Problem solved, right? Well, maybe. What that error really means is your system can’t cryptographically verify the packages coming from a specific repository. You’re being told that something in your software supply chain is untrusted, or at least, unverified. Blindly fixing it can be a quick path to a compromised system. I’ve seen teams brush this off until a critical system mysteriously gains unexpected packages.

Decoding the NO_PUBKEY message: What APT’s *really* saying

When APT runs ‘update’, it fetches more than just package lists. For each repository, it grabs a ‘Release’ file and a ‘Release.gpg’ file. The ‘Release.gpg’ is a GPG signature for the ‘Release’ file itself. And the ‘Release’ file contains checksums for all the actual package index files (like ‘Packages.gz’ or ‘Sources.gz’). It’s a chain of trust: if the Release.gpg signature doesn’t validate against a known public key, or if the key itself is missing or expired, the whole chain breaks down. APT refuses to trust anything from that repository, and it’ll yell ‘NO_PUBKEY’ because it doesn’t have the public key to verify that GPG signature. It’s a security feature, not just an annoyance.

The legacy ‘apt-key’ approach (and why you should stop using it)

For years, the standard fix involved ‘apt-key add’. You’d curl a public key, pipe it to ‘apt-key add -‘, and magically, the errors went away. But here’s the kicker: ‘apt-key’ essentially dumps all those public keys into a global trust keyring, typically in ‘/etc/apt/trusted.gpg.d/’. This means *any* key added via ‘apt-key’ becomes trusted for *all* APT repositories on your system. If even one of those third-party repositories gets compromised, and its key is globally trusted, it could push malicious packages onto your system that APT would happily install. This isn’t just theoretical; it’s a gaping security hole many of us overlooked for too long.

The ‘right way’ to manage repository keys today

curl -fsSL download.docker.com/linux/debian/gpg | gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] download.docker.com/linux/debian $(lsb_release -cs) stable" | tee /etc/apt/sources.list.d/docker.list > /dev/null
apt update

• Granular trust: The public key is explicitly tied to a specific repository in the ‘sources.list’ entry.
• Clear audit trail: You can see exactly which key applies to which source file.
• Isolated keys: Keys are stored as individual files, not a monolithic, globally trusted keyring. If one repo’s key is compromised, it only affects that repo.

This modern approach uses the `signed-by=` option in your `/etc/apt/sources.list.d/` entries. You download the public key, typically `gpg –dearmor` it into a standard `.gpg` file (often in `/usr/share/keyrings/`), and then reference that specific file in your repository definition. This way, that key is only trusted for that one specific repository. It dramatically reduces your blast radius if a third-party repo goes sideways. It’s a bit more typing upfront, but it pays dividends in peace of mind.

Sometimes keys legitimately change or expire. A ‘NO_PUBKEY’ or ‘Key expired’ error means you need to get a new public key. Always check the vendor’s official documentation for the updated key and installation instructions. Don’t just blindly grab a key from some forum post. This isn’t about convenience; it’s about maintaining a robust software supply chain on your servers. Knowing how this works means you’re not just making the error messages go away, you’re actually securing your systems.