Linux ID: Linux explores new way of authenticating developers and their code
Follow ZDNET: Add us as a preferred source on Google.
ZDNET's key takeaways
- The Linux kernel is moving toward a better way of identifying developers and their code.
- This new approach can be used by other open-source projects.
- It's not being rolled out yet, but I expect it to be deployed by this time next year.
NAPA, Calif. -- In the immortal words of song developer Pete Townshend, "Well, who are you? (Who are you? Who, who, who, who?) I really wanna know!" Linux kernel maintainers have the same question: Who are their programmers, and how can the kernel community be sure the code they submit is really theirs?
For decades, Linux kernel developers used Pretty Good Privacy (PGP) to identify developers and their release artifacts. Git's PGP integration enabled signed tags to verify code repository integrity and signed commits to prevent hackers from impersonating legitimate developers.
Also: The latest Linux kernel release closes out the 6.x era - and it's a gift to cloud admins
In 2011, hackers successfully cracked the main Linux development site, kernel.org. Afterward, to make sure this didn't happen again, the kernel's PGP web of trust was explicitly "bootstrapped" at a face-to-face key‑signing session during the 2011 Kernel Summit.
More recently, the xz utility was compromised by a malicious developer, almost leading to malware infecting Linux.
A painful process
Today, kernel maintainers who want a kernel.org account must find someone already in the PGP web of trust, meet them face‑to‑face, show government ID, and get their key signed. The process is like a manual, global scavenger hunt. Linux kernel maintainer Greg Kroah-Hartman, speaking at the Linux Foundation Members Summit, described it as a "pain to do and manage." That's because it's tracked by manual scripts, the keys drift out of date, and the public "who lives where" map creates privacy and social‑engineering risk.
Therefore, the kernel maintainers are working to replace this fragile PGP key‑signing web of trust with a decentralized, privacy‑preserving identity layer that can vouch for both developers and the code they sign.
Also: This backdoor almost infected Linux everywhere: The XZ Utils close call
Their new approach, which I'll call Linux ID, was presented this week by Linux Foundation Decentralized Trust leaders Daniela Barbosa and Hart Montgomery, along with partner Glenn Gore, CEO of Affinidi, an open-standard digital trust company. Linux ID is meant to give the kernel community a more flexible way to prove who people are, and who they're not, without falling back on brittle key‑signing parties or ad‑hoc video calls.
At the core of Linux ID is a set of cryptographic "proofs of personhood" built on modern digital identity standards rather than traditional PGP key signing. Instead of a single monolithic web of trust, the system issues and exchanges personhood credentials and verifiable credentials that assert things like "this person is a real individual," "this person is employed by company X," or "this Linux maintainer has met this person and recognized them as a kernel maintainer."
Issuer‑agnostic and composable
These credentials can be anchored in multiple ways: Government-issued digital IDs, where available; third‑party identity verifiers similar to visa application centers; employers; or the Linux Foundation itself acting as an issuer.
Montgomery stressed that the model is intentionally issuer‑agnostic and composable: if two developers share trust in different issuers, they can still find overlapping trust paths, and the more independent issuers exist, the stronger the overall system becomes.
Technically, Linux ID is built around decentralized identifiers (DIDs). This is a W3C‑style mechanism for creating globally unique IDs and attaching public keys and service endpoints to them. Developers create DIDs, potentially using existing Curve25519‑based keys from today's PGP world, and publish DID documents via secure channels such as HTTPS‑based "did:web" endpoints that expose their public key infrastructure and where to send encrypted messages.
On top of that, the project uses a decentralized messaging fabric that can be REST, DIDComm, or another trust‑spanning protocol. This enables participants to establish relationships and exchange credentials without revealing their physical location or network topology. Each relationship uses its own random, ephemeral DIDs, making it far harder for observers running messaging infrastructure to infer who is talking to whom or to map the kernel's social graph.
In a live demo, Gore walked through how a new developer with no prior credentials spins up an identity, joins a Linux Foundation community, and then establishes a relationship with another participant using pairwise DIDs. Once that relationship exists, the two sides can exchange richer, verifiable relationship credentials (VRCs) that record facts such as when the relationship started, the level of trust it reflects, and how long the credential should remain valid.
Also: AI is creeping into the Linux kernel - and official policy is needed ASAP
For kernel maintainers, the idea is that these credentials would back the identities behind signed code: instead of relying solely on a PGP key signed at a conference years ago, maintainers could check a bundle of fresh credentials proving that the key they see belongs to the same person recognized by the Linux Foundation, their employer, or other trusted issuers. These credentials can be fed into transparency logs and other audit systems.
Montgomery and others were careful to say that Linux ID will not magically prevent another xz‑style supply‑chain attack, but they argue it materially raises the cost. Instead of a single PGP key and a handful of signatures, an attacker would need to accumulate and maintain multiple, short‑lived credentials from issuers that can revoke them and from community members whose own reputations are in play, all while their activity is streamed into public or semi‑public transparency logs.
It's a technology stack, not a fixed policy
The system's design also pushes toward shorter‑lived attestations: issuers are encouraged to issue credentials valid for days or weeks, not years, and to rely on trust registries that can flag revoked credentials even if the issuer and holder are no longer in direct contact. That combination of rolling credentials and registry‑backed revocation gives the community more levers to respond when a contributor turns out not to be who they claimed to be or when a real developer's device or keys are compromised.
Also: Why my favorite Linux distro is slowing down - and I'm thrilled about it
One theme reiterated throughout the session was that Linux ID is a technology stack, not a fixed policy. Different communities, from the core kernel to other Linux Foundation projects, will be able to choose which issuers they trust, what level of proof they require for different roles, and whether AI agents can act under delegated credentials to perform automated tasks like continuous integration or patch testing.
The same mechanisms that let a maintainer vouch for a human contributor can cryptographically delegate limited authority to an AI agent or service, with separate credentials and trust contexts that can be revoked independently if something goes wrong. Researchers from the Harvard Applied Social Media Lab and others are already experimenting with compatible apps that blend human and AI participants in the same credential‑aware conversations, hinting at how Linux ID might intersect with future developer tooling.
Linux ID has yet to be deployed. Kroah‑Hartman said the effort is still in an exploratory and prototyping stage. The plan is to take the discussion to Linux Plumbers and the Kernel Summit over the coming year. In the near term, kernel.org could import its existing PGP web of trust into the new system to ease migration, while maintainers begin testing the tools in parallel with today's PGP‑based processes.
Also: I found the best Linux server distros for your home lab
Barbosa and others framed the work as part of a broader push for the Linux Foundation to lead on decentralized trust infrastructure. In other words, this technology isn't just for kernel developers. It's for any open-source community or AI‑driven ecosystem facing a rapidly worsening identity and authenticity crisis.
Once deployed, future developers and code will be backed not only by a signed tag but by a rich, cryptographically verifiable story about who stands behind it. This means Linux code will be safer than ever.