Code signing answers a narrow question: did the artifact come from the holder of a particular private key, and has it changed since signing? It does not answer whether that holder is a person, a CI runner, or a laptop left unlocked. Before you click update, the signer identity is worth more attention than the version number.

The Trust Behind the Update Button

Signing works through a cryptographic hash. The build is hashed, the hash is signed with a private key, and the verifier recomputes the hash and checks the signature against the matching public key. If either the bytes or the signature mismatch, verification fails. That is the whole mechanism, and it is genuinely useful.

What it does not do is attach a human to the key. A signature proves possession at signing time. It says nothing about whether the maintainer was pressured, phished, or replaced by a token sitting in a shared CI secret. The update prompt compresses all of that into a badge and a version string.

Most users never inspect the signer. On mobile platforms the operating system checks the certificate chain and the user sees a familiar app name. On desktop, package managers verify a repository signature and move on. The trust has already been delegated by the time the dialog appears.

The delegation has layers worth naming. A mobile app store signs its own manifest over your binary, so the chain you actually trust runs through the store operator rather than the developer. A Linux distribution signs package indexes with a repository key that a release engineer holds, and the individual .deb or .rpm inside carries a weaker or absent signature of its own. Windows installers sit somewhere in between, with an Authenticode certificate that may belong to a company legal entity nobody on the engineering team can name. Each layer moves the human further from the artifact.

There is a practical consequence for incident response. When a signature turns out to be bad, the first question anyone asks is which human signed it, and the layered chain is exactly what makes that question slow to answer. Store operators hold logs you cannot read. Distribution keyrings are maintained by volunteers on their own time. The forensic trail exists, but it is scattered across organizations that have no shared obligation to hand it over quickly.

Where the Keys Actually Live

Ask a small project where its release signing key is stored and the honest answer is often a single laptop, sometimes in a home directory with a passphrase that has not changed in years. Larger projects do better, but adoption of hardware tokens is uneven across ecosystems and often depends on whether someone donated devices.

Hardware tokens help because the private key never leaves the device; the signing operation happens inside it. That raises the cost of exfiltration considerably. It does not help if the token is left plugged into a build machine, or if the PIN is stored next to it in a password manager shared by the team.

CI runners are the other common home. A long-lived signing secret exported as an environment variable gives every job on that runner the ability to produce a valid release. Rotation is rare and usually manual, which means a leaked secret can stay valid long after anyone notices. A related piece on this site about who pays for CI minutes touches the same budget tension that keeps rotation work unstaffed.

There is a middle path some projects take: an offline signing host that is powered on only for releases, reached over a jump box, with the key on an encrypted disk inside. It is cheaper than a token per maintainer and more annoying than a CI secret, which is roughly the right trade for a project with two releases a month. The failure mode is drift. The offline host gets promoted to always-on because someone needed it for a hotfix, and the isolation quietly disappears.

Key type matters too, and it is one of the few things you can check without asking anyone. Older projects still ship RSA keys of a size that felt generous a decade ago; newer setups lean toward elliptic-curve keys that are shorter and faster to verify. Neither choice is wrong on its own. What matters is whether the key type and size are documented somewhere a stranger can read, because an undocumented key is a key you cannot reason about when a release looks odd.

Bus Factor Behind a Release

One maintainer, one key, one point of failure. That is the shape of a great many projects, including some that sit underneath large commercial products. The signer list is often shorter than the contributor list by an order of magnitude, and sometimes it is a list of one.

Burnout shrinks the pool further. A maintainer who steps back usually hands over commit access before signing authority, because the key is the awkward part. Nobody wrote down the procedure, so the key stays with the person who is leaving, or gets copied to a successor over an insecure channel in a hurry.

Funding rarely covers key custody. Sponsorship pays for bug fixes and review time, not for a safe deposit box, a spare token, or the afternoon spent documenting a revocation path. This site has argued that license terms and vendor support contracts pull in different directions on exactly this kind of unglamorous maintenance.

Small projects mirror large supply chains. A two-person library with a single signing key can end up inside a bank's build. The dependency graph does not care about the size of the signer pool, and neither does an attacker.

Count the signers, not the commits. A repository with a thousand contributors and one release key has a bus factor of one for everything that matters at install time. That number is easy to check and rarely checked, because it lives in a file most contributors never open.

Handover is where the bus factor gets decided in practice. A good handover looks boring: the outgoing maintainer signs a document naming the successor, the new key is published alongside the old fingerprint, and there is a stated overlap window during which both keys are valid. A bad handover is a direct message that says the key is in the shared drive now. The difference costs an afternoon and saves whoever inherits the project a month of guessing.

Auditing the Signer Before You Install

Check the signer identity, not just the presence of a signature. On platforms that expose it, read the certificate subject and the issuing authority. If the signature is valid but the identity is a generic automation account with no published mapping to a maintainer, you have learned something useful.

Compare the key against the project's published fingerprint. Many repositories now publish signer fingerprints in a README, a signed tag, or a keys directory. If the fingerprint in the release does not match the published one, stop and find out why before installing.

Watch for silent key changes between releases. A new key with a plausible story is exactly what a compromise looks like from the outside. Projects that rotate properly announce the change in advance and sign the announcement with the old key.

Read the security.txt contact path. The standard places a machine-readable file at a well-known location so researchers can report vulnerabilities. A project with no reachable security contact has no practical way to tell you that a key was revoked, which makes every subsequent release harder to judge.

Build a small habit around the check. Keep the fingerprints you have verified in a local file with the date you confirmed them, and diff it when a release arrives. The diff is usually empty, which is the point. When it is not empty, you have a dated record of what changed and a concrete question to send to the maintainers rather than a vague feeling that something looked off.

When you find a gap, the cheapest fix is often a documentation patch rather than a policy argument. Open an issue asking where the release fingerprint is published, and offer to add the section yourself. Maintainers who are underwater on review will usually take a pull request that writes down what they already know. Do this before the next release, and you will have moved the signer identity from tribal knowledge into a file that a stranger can check.