What is really sad, is that this could be a good pen-test for the kernel. Especially the idea of introducing bugs that are only vulnerabilities when they all come in together.<p>If only they had contacted the Linux Foundation ahead of time to get permission, and set up terms, like a real pen-test. Then work could be done on detecting, and preventing these sorts of attacks, maybe resulting in a system that could help everyone. At the very least a database for security researchers that are registered, but unknown to maintainers, where they could store hashes of bad commits. Then a check if any of those commits made it through. I know the kernel makes use of rebasing, so that might not be the best approach technically, but something like that. To ease the pain of wasting developers time, sponsors could put up money that the maintainer gets if they catch it, and maybe a smaller amount if they have to revert it.<p>EDIT: if the Linux Foundation said no, they could have tried another large open source project with a governing body, Apache, Python, Postgres, Firefox, etc. It wouldn't have been as flashy and high profile, but it would have still been the same research, and odds are you would find at least one project willing to participate.
Just to clarify, all the proposals that were intentionally vulnerable and were really vulnerabilities were not accepted in the first place. However, that event triggered review of all University of Minnesota proposals, and that's what's being discussed here.
Just from a code quality process standpoint, that’s an interesting result. Now I’m wondering what would happen if you picked a set of 150 random kernel patches and told 80 reviewers to re-review them assuming they could be malicious. I bet you’d find quite a few fixes.
Isn't the moral of the story here that it's probably trival for organizations like the FSB/NSA/Chinese equivalent to get malicious patches accepted into Linux.
As usual, The Onion anticipated this: <a href="https://youtu.be/FpN_RjIaVw8" rel="nofollow">https://youtu.be/FpN_RjIaVw8</a>
Maybe the people reviewing the changes should be unaware of who made them. I am biased and for sure look more closely at some developers pull requests than others.
honestly fsck these "pen testers", spend some time trying to make things better rather than trying to break shit and finger pointing.<p>Starting to feel like pen testing is a broken profession.
The moral of this story is this: whatever you do, don't be the dweeb that gets their code closely reviewed by the kernel maintainers. (You are actually better off having it reviewed tho)
The guilt by association here is now approaching Biblical scales. Like the guy in the comments who wants to close down the entire Computer Science and Electrical Engineering departments at UMN, which probably employ/educate the best part of a thousand people. Ha!<p>In general, the fury and seethe which this experiment inspired is amazing. IMO the real disgrace is not the experiment itself, but the response. The kernel developers need to stop being martyrs and playing blame games. They need to be rational and take responsibility for improving their own procedures. Because, if they didn't already have them, governments now have entire departments studying how to use deliberate vulnerabilities in open source projects, for military intelligence and other purposes. And they will not be deterred by the continued public flogging of the University of Minnesota.