Maintaining the kernel's web of trust
Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing
By Jonathan Corbet September 4, 2019 A typical kernel development cycle involves pulling patches from over 100 repositories into the mainline. Any of those pulls could conceivably bring with it malicious code, leaving the kernel (and its users) open to compromise. The kernel's web of trust helps maintainers to ensure that pull requests are legitimate, but that web has become difficult to maintain in the wake of the recent attacks on key servers and other problems. So now the kernel community is taking management of its web of trust into its own hands.
As recently as 2011, there was no mechanism in place to verify the provenance of pull requests sent to kernel maintainers. If an emailed request looked legitimate, and the proposed code changes appeared to make sense, then the requested pull would generally be performed. That degree of openness makes for a low-friction development experience, but it also leaves the project open to at least a couple types of attacks. Email is easy to forge; an attacker could easily create an email that appeared to be from a known maintainer, but which requested a pull from a malicious repository.
The risk grows greater if an attacker somehow finds a way to modify a maintainer's repository (on kernel.org or elsewhere); then the malicious code would be coming from a trusted location. The chances of a forged pull request from a legitimate (but compromised) repository being acted on are discouragingly high.
