"If kernel developers worked by shipping simple files of source code around, they might well be vulnerable to malware added by an intruder," Corbet explained. "But that is not how kernel development is done."

Git's hash function produces 160-bit numbers, Corbet noted, and any time the contents of a file change, the hash does too. "An attacker would be unable to change a file without changing its hash as well. Git checks hashes regularly, so a simplistic attempt to corrupt a file would be flagged almost immediately," he pointed out.

'It Would Be Immediately Apparent'

Then, too, there's the fact that "for any given state of the kernel source tree, git calculates a hash based on (1) the hashes of all the files contained within that tree, and (2) the hashes of all of the previous states of the tree," Corbet added. "So, for example, the hash for the kernel at the 3.0 release is 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe. There is no way to change any of the files within that release - or within any previous release - without changing that hash. If anybody (even the kernel.org repository) were to present a 3.0 kernel with a different hash, it would be immediately apparent that something was not right."

Further explanation can be found in a from Git developer Junio C. Hamano, as on The H, providing even more technical detail.