Git signatures will remain, but the identity of maintainers and patch authors will be verified through a new layer of decentralized trust.
"Who are you, and why should the Linux kernel trust you?" In the kernel development community, this question has long ceased to be a joke. Following the xz Utils incident and other alarming episodes, Linux maintainers are seriously searching for a new way to verify the identities of contributors and verify the origin of code without the old, cumbersome, and inconvenient PGP (Pretty Good Privacy, a public-key encryption standard) scheme.
For many years, kernel developers relied on PGP. Git signatures helped confirm the integrity of repositories and protected against commit author spoofing. After the kernel.org hack in 2011, the community even deliberately "reset" trust through an in-person key signing session at the Kernel Summit to strengthen the system. The approach worked, but over time, it accumulated too many problems.
Currently, the path to a kernel.org account for a new maintainer feels like a bureaucratic quest across the globe. You need to find someone within PGP's web of trust, meet in person, show proof of identity, and get a key signed. Greg Kroah-Hartman, at the Linux Foundation summit, directly described the process as painful to maintain and manage. The team uses manual scripts to manage the account, keys become outdated, and the public map of "who lives where" adds privacy and social engineering risks .
To replace this system, a new system, referred to in the article as Linux ID, is being developed. The idea was presented by Daniela Barbosa and Hart Montgomery, heads of decentralized trust at the Linux Foundation, along with Glenn Gore, CEO of Affinidi. The goal is simple yet ambitious: to give the community a way to verify a developer's identity and the authenticity of their digital actions without the fragility of in-person "signing parties" and random video calls.
Instead of the classic web of trust, PGP Linux ID offers a digital identity layer based on modern cryptographic identity verification. The system operates through a set of verifiable credentials that can prove various facts: that the community is a real person, that the participant works for a specific company, or that another maintainer personally knows the developer and confirms their status in the kernel ecosystem.
The key idea behind Linux ID is flexibility. The source of trust could be a government-issued digital identity (if such infrastructure is available), an external identity verification service similar to visa centers, an employer, or the Linux Foundation itself. Montgomery emphasized that the model isn't tied to a single "correct" issuer. Even if two developers trust different organizations, the system can still find overlapping trust relationships. The more independent issuers, the more robust the overall design.
The technical foundation of Linux ID is built around decentralized identifiers (DIDs) in the spirit of W3C (World Wide Web Consortium) standards. A developer creates such an ID, can use existing Curve25519 keys from current PGP practices, and then publishes the DID document via secure channels—for example, via did:web over HTTPS. The DID document stores public keys and service points through which participants exchange encrypted messages.
A messaging layer compatible with REST (a standard for web service interaction), DIDComm, or other protocols across different trust zones operates on top of the identifiers. This architecture allows for the building of relationships and the transfer of credentials without revealing the physical location of participants or the network topology. Separate, random, short-lived, pairwise decentralized identifiers are used for each connection. This makes it significantly more difficult for an observer to understand who is communicating with whom and to construct the social graph of the core community.
During the demonstration, Glenn Gore demonstrated the path for a new developer without previous credentials. A participant creates a digital identity, joins the Linux Foundation community, and then establishes a connection with another participant through pairwise decentralized identifiers. Once the connection is established, the parties can exchange more meaningful, verifiable relationship credentials. This set records the connection start date, trust level, and validity period of the confirmation.
For kernel maintainers, the practical implications are as follows. Instead of verifying a single PGP key with a signature obtained at a conference many years ago, the maintainer will be able to view a recent confirmation packet. This packet will demonstrate that the current key does indeed belong to the same person known to the Linux Foundation, their employer, or other trusted issuers. Additionally, this data can be fed into transparency logs and other audit systems.
The project's authors don't promise miracle protection against a new attack on the level of xz Utils. Linux ID won't eliminate the risk of supply chain compromise, but it will significantly increase the cost of an attack. Instead of a single key and multiple signatures, an attacker will have to obtain and maintain multiple short-lived confirmations from different issuers, monitor their reputation within the community, and operate under the surveillance of transparent logs where activity is public or semi-public.
The Linux ID architecture also encourages short validation lifetimes. Issuers are encouraged to issue credentials for days or weeks, rather than years, and to rely on trust registries with revocation records. The combination of rapid updates and revocation registries gives the community more leverage when a participant impersonates someone else or when a legitimate developer's device or keys are compromised.
A key point was reiterated during the session: Linux ID does not dictate a uniform policy for all projects. It's about a technology stack, not a rigid set of regulations. The kernel community and other Linux Foundation projects will be able to independently choose trusted issuers, the required level of verification for different roles, and the operating rules for automated agents.
The same mechanism allows not only for human verification but also for limited delegation of authority to AI agents or services for automated tasks like continuous integration (CI) and patch testing. Separate credentials can be issued for such agents and their access revoked independently of human interaction. Researchers from the Harvard Applied Social Media Lab and other organizations are already experimenting with interoperable applications where humans and AI participants communicate in the same environment, taking into account trust contexts.
The actual implementation of Linux ID is still a long way off. Greg Kroah-Hartman said the work remains in the research and prototyping phase. Discussions are planned for Linux Plumbers and Kernel Summit within the next year. Initially, kernel.org may import the existing PGP Web of Trust into the new system to smooth the migration and allow maintainers to test the tools in parallel with their current processes.
The Linux Foundation views the project more broadly than just a single kernel. Barbosa and colleagues describe Linux ID as part of a commitment to a decentralized trust infrastructure for open communities and AI ecosystems, where the crisis of authenticity and identity is rapidly intensifying. If the project reaches production, a Git tag signature will no longer be the sole source of trust. Instead of a single digital signature, there will be a complete, cryptographically verifiable history of the individual and the organizations that support their reputation. This shift could significantly strengthen trust in the Linux code and its development process.
"Who are you, and why should the Linux kernel trust you?" In the kernel development community, this question has long ceased to be a joke. Following the xz Utils incident and other alarming episodes, Linux maintainers are seriously searching for a new way to verify the identities of contributors and verify the origin of code without the old, cumbersome, and inconvenient PGP (Pretty Good Privacy, a public-key encryption standard) scheme.
For many years, kernel developers relied on PGP. Git signatures helped confirm the integrity of repositories and protected against commit author spoofing. After the kernel.org hack in 2011, the community even deliberately "reset" trust through an in-person key signing session at the Kernel Summit to strengthen the system. The approach worked, but over time, it accumulated too many problems.
Currently, the path to a kernel.org account for a new maintainer feels like a bureaucratic quest across the globe. You need to find someone within PGP's web of trust, meet in person, show proof of identity, and get a key signed. Greg Kroah-Hartman, at the Linux Foundation summit, directly described the process as painful to maintain and manage. The team uses manual scripts to manage the account, keys become outdated, and the public map of "who lives where" adds privacy and social engineering risks .
To replace this system, a new system, referred to in the article as Linux ID, is being developed. The idea was presented by Daniela Barbosa and Hart Montgomery, heads of decentralized trust at the Linux Foundation, along with Glenn Gore, CEO of Affinidi. The goal is simple yet ambitious: to give the community a way to verify a developer's identity and the authenticity of their digital actions without the fragility of in-person "signing parties" and random video calls.
Instead of the classic web of trust, PGP Linux ID offers a digital identity layer based on modern cryptographic identity verification. The system operates through a set of verifiable credentials that can prove various facts: that the community is a real person, that the participant works for a specific company, or that another maintainer personally knows the developer and confirms their status in the kernel ecosystem.
The key idea behind Linux ID is flexibility. The source of trust could be a government-issued digital identity (if such infrastructure is available), an external identity verification service similar to visa centers, an employer, or the Linux Foundation itself. Montgomery emphasized that the model isn't tied to a single "correct" issuer. Even if two developers trust different organizations, the system can still find overlapping trust relationships. The more independent issuers, the more robust the overall design.
The technical foundation of Linux ID is built around decentralized identifiers (DIDs) in the spirit of W3C (World Wide Web Consortium) standards. A developer creates such an ID, can use existing Curve25519 keys from current PGP practices, and then publishes the DID document via secure channels—for example, via did:web over HTTPS. The DID document stores public keys and service points through which participants exchange encrypted messages.
A messaging layer compatible with REST (a standard for web service interaction), DIDComm, or other protocols across different trust zones operates on top of the identifiers. This architecture allows for the building of relationships and the transfer of credentials without revealing the physical location of participants or the network topology. Separate, random, short-lived, pairwise decentralized identifiers are used for each connection. This makes it significantly more difficult for an observer to understand who is communicating with whom and to construct the social graph of the core community.
During the demonstration, Glenn Gore demonstrated the path for a new developer without previous credentials. A participant creates a digital identity, joins the Linux Foundation community, and then establishes a connection with another participant through pairwise decentralized identifiers. Once the connection is established, the parties can exchange more meaningful, verifiable relationship credentials. This set records the connection start date, trust level, and validity period of the confirmation.
For kernel maintainers, the practical implications are as follows. Instead of verifying a single PGP key with a signature obtained at a conference many years ago, the maintainer will be able to view a recent confirmation packet. This packet will demonstrate that the current key does indeed belong to the same person known to the Linux Foundation, their employer, or other trusted issuers. Additionally, this data can be fed into transparency logs and other audit systems.
The project's authors don't promise miracle protection against a new attack on the level of xz Utils. Linux ID won't eliminate the risk of supply chain compromise, but it will significantly increase the cost of an attack. Instead of a single key and multiple signatures, an attacker will have to obtain and maintain multiple short-lived confirmations from different issuers, monitor their reputation within the community, and operate under the surveillance of transparent logs where activity is public or semi-public.
The Linux ID architecture also encourages short validation lifetimes. Issuers are encouraged to issue credentials for days or weeks, rather than years, and to rely on trust registries with revocation records. The combination of rapid updates and revocation registries gives the community more leverage when a participant impersonates someone else or when a legitimate developer's device or keys are compromised.
A key point was reiterated during the session: Linux ID does not dictate a uniform policy for all projects. It's about a technology stack, not a rigid set of regulations. The kernel community and other Linux Foundation projects will be able to independently choose trusted issuers, the required level of verification for different roles, and the operating rules for automated agents.
The same mechanism allows not only for human verification but also for limited delegation of authority to AI agents or services for automated tasks like continuous integration (CI) and patch testing. Separate credentials can be issued for such agents and their access revoked independently of human interaction. Researchers from the Harvard Applied Social Media Lab and other organizations are already experimenting with interoperable applications where humans and AI participants communicate in the same environment, taking into account trust contexts.
The actual implementation of Linux ID is still a long way off. Greg Kroah-Hartman said the work remains in the research and prototyping phase. Discussions are planned for Linux Plumbers and Kernel Summit within the next year. Initially, kernel.org may import the existing PGP Web of Trust into the new system to smooth the migration and allow maintainers to test the tools in parallel with their current processes.
The Linux Foundation views the project more broadly than just a single kernel. Barbosa and colleagues describe Linux ID as part of a commitment to a decentralized trust infrastructure for open communities and AI ecosystems, where the crisis of authenticity and identity is rapidly intensifying. If the project reaches production, a Git tag signature will no longer be the sole source of trust. Instead of a single digital signature, there will be a complete, cryptographically verifiable history of the individual and the organizations that support their reputation. This shift could significantly strengthen trust in the Linux code and its development process.
