The Linux Kernel Trusts Your Code. Should It Trust You?

In early 2024, a carefully devised supply-chain attack made it into released versions of one of Linux’s most widely distributed utilities before being caught by chance. The attacker had spent nearly three years building a credible contributor reputation before using it to introduce malicious code into XZ utils. It was not caught by any verification system. It was caught by an engineer who noticed an unusual performance anomaly.

That detail matters. One of the most consequential security breaches in open-source history was discovered by accident.

The Linux kernel community has been sitting with that fact. The system currently used to verify who is contributing to the kernel, i.e., a PGP web of trust built on face-to-face key-signing rituals, was not designed for the threat environment we are now in. It is difficult to scale, painful to maintain, and, as XZ demonstrated, a determined attacker with patience can break the cryptography. They just need to become someone the community trusts.

At the Linux Foundation Decentralised Trust Summit in February, Affinidi CEO Glenn Gore joined kernel maintainer Greg Kroah-Hartman and the LFDT team to present and demonstrate a proposed alternative: Linux ID, a decentralised approach to contributor authentication built on cryptographic proofs of personhood and verifiable relationship credentials.

The proposal replaces the key-signing ceremony with something functionally equivalent but structurally harder to deceive. A contributor establishes their identity through a recognised issuer, such as an employer, a government authority, or the Linux Foundation itself, and receives a credential proving they are a real, verified person, without exposing their underlying personal data. When a trusted maintainer vouches for them, that vouching becomes a verifiable relationship credential: cryptographically signed, time-bounded, and revocable. Not a static entry in a manually maintained database, but a living attestation that can be updated, withdrawn, and composed with others to form a verifiable picture of who someone actually is in a community over time.

Does this eliminate supply chain attacks? It does not. As Glenn put it at the summit, “it doesn’t completely erase it, it just raises the cost.” Corrupting a contributor with a deep, cryptographically verifiable trust history across multiple independent issuers is considerably harder than exploiting someone who built a modest reputation over a short period. The attack surface becomes smaller and more expensive, not impossible, but meaningfully different from the world the XZ attacker operated in, where patience alone was sufficient.

Glenn demonstrated the full identity lifecycle live at the summit, creating an identity from zero, publishing a decentralised identifier, establishing a peer-to-peer relationship, and issuing a verifiable relationship credential between two parties with no third party involved. You can watch the full session here:

Earlier that week, the same technology had been tested at the Summit on Human Agency, where 200 attendees made 251 peer-to-peer connections and exchanged 148 verifiable relationship credentials across a single day. The significance of those numbers lies not in their scale but in the fact that they came from people who had never encountered this technology before, with no prior training.

Linux ID is still being explored. The kernel community will continue working on how it integrates with existing contributor workflows, and the team will engage with Linux Plumbers and the Kernel Summit over the coming year. For contributors already in the current web of trust, existing Curve 25519 keys can be imported directly.

The open-source community has spent decades building extraordinarily rigorous systems for trusting code. The question Linux ID is asking, quietly, collaboratively, and without fanfare, is whether the humans behind that code deserve the same rigour. The answer, given what happened with XZ, seems obvious. The hard part is always the infrastructure.

For the strategic case for Affinidi’s open-source approach, read “Open by Design: Building Trust Infrastructure in Public.”