Given the size and complexity of the Linux (/GNU) codeworld, I have to wonder if they are coming up against (or already did) the practical limits of assuring safety and quality using the current model of development.
“They introduce kernel bugs on purpose”
241–250 of 1001 posts
Re: “They introduce kernel bugs on purpose”
#242Re: “They introduce kernel bugs on purpose”
#243Earlier quoted context omitted.
> I think all patches have come from people currently being advised by Kangjie Liu[3] or Liu himself dating back to Dec 2018 New plan: Show up at Liu's house with a lock picking kit while he's away at work, pick the front door and open it, but don't enter. Send him a photo, "hey, just testing, bro! Legitimate security research!"
If they wanted to do security research, they could have done so in the form of asking the reviewers to help; send them a patch and ask 'Is this something you would accept?', instead of intentionally sending malicious commits and causing static on the commit tree and mailing lists.
Notify someone up the chain that you want to submit malicious patches, and ask them if they want to collaborate.
If your patches make it through, treat it as though they essentially just got red teamed, everyone who reviewed it and let it slip gets to have a nervous laugh and the commit gets rejected, everyone having learned something.
Re: “They introduce kernel bugs on purpose”
#244Earlier quoted context omitted.
If the IRB is any good the professor doesn't get that. Universities are publish or perish, and the IRB should force the withdrawal of all papers they submitted. This is might be enough to fire the professor with cause - including remove any tenure protection they might have - which means they get a bad reference. I hope we hear from the IRB in about a year stating exactly what happened. Real investigations of bad con…
See page 9 of the already published paper: https://raw.githubusercontent.com/QiushiWu/qiushiwu.github.i... > We send the emails to the Linux communityand seek their feedback. The experiment is not to blame any maintainers but to reveal issues in the process. The IRB of University of Minnesota reviewed the procedures of the experiment and determined that this is not human research. We obtained a formal IRB-exempt lett…
That's not really what they did.
They sent the patches, the patches where either merged or rejected.
And they never let anybody knew that they had introduced security vulnerabilities on the kernel on purpose until they got caught and people started reverting all the patches from their university and banned the whole university.
Re: “They introduce kernel bugs on purpose”
#245The professor gets exactly what they want here, no? "We experimented on the linux kernel team to see what would happen. Our non-double-blind test of 1 FOSS maintenance group has produced the following result: We get banned and our entire university gets dragged through the muck 100% of the time". That'll be a fun paper to write, no doubt. Additional context: * One of the committers of these faulty patches, Aditya Pak…
Hearing how you phrased it reminds me of a study that showed how parachutes do not in fact save lives (the study was more to show the consequences of extrapolating data, so the result should not be taken seriously): https://www.bmj.com/content/363/bmj.k5094
Re: “They introduce kernel bugs on purpose”
#246I feel like q lot of people here did not interpret this correctly. As far as it's known, garbage code was not introduced into kernel.It was caught in the review process literally on the same day. However, there has been merged code from the same people, which is not necessarily vulnerable. As a precaution the older commits are also being reverted, as these people have been identified as bad actors
That means that the researchers got bogus code into the kernel, got it accepted, and then said nothing for two weeks as the bogus commit spread through the Linux development process and ended up in the stable tree, and, potentially, in forks.
Re: “They introduce kernel bugs on purpose”
#247Re: “They introduce kernel bugs on purpose”
#248Earlier quoted context omitted.
If the IRB is any good the professor doesn't get that. Universities are publish or perish, and the IRB should force the withdrawal of all papers they submitted. This is might be enough to fire the professor with cause - including remove any tenure protection they might have - which means they get a bad reference. I hope we hear from the IRB in about a year stating exactly what happened. Real investigations of bad con…
See page 9 of the already published paper: https://raw.githubusercontent.com/QiushiWu/qiushiwu.github.i... > We send the emails to the Linux communityand seek their feedback. The experiment is not to blame any maintainers but to reveal issues in the process. The IRB of University of Minnesota reviewed the procedures of the experiment and determined that this is not human research. We obtained a formal IRB-exempt lett…
It is likely the professor involved here will be fired if they are pre-tenure, or sanctioned if post-tensure.
Re: “They introduce kernel bugs on purpose”
#249I would check their ties to nation-state actors. In closed source, nobody would even check. Modern DevOps has essentially replaced manual code review with unit tests.
Re: “They introduce kernel bugs on purpose”
#250Earlier quoted context omitted.
Hearing how you phrased it reminds me of a study that showed how parachutes do not in fact save lives (the study was more to show the consequences of extrapolating data, so the result should not be taken seriously): https://www.bmj.com/content/363/bmj.k5094
This is now my second favourite paper after the atlantic salmon in fmri