Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

261–270 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#261
post #22

Later down thread from Greg K-H: > Because of this, I will now have to ban all future contributions from your University. Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota. EDIT: Searching through the source code[1] reveals contributions to the kernel from umn.edu emails in the form of an AppleTalk driver and support for the kernel on PowerPC architectures. In t…

> 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!"

I wouldn't be surprised if the good, conscientious members of the UMN community showed up at his office (or home) door to explain, in vivid detail, the consequences of doing unethical research.

Re: “They introduce kernel bugs on purpose”

#262

The 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…

> The thread then gets down to business and starts coordinating revert patches for everything committed by University of Minnesota email addresses. What's preventing those bad actors from not using a UMN email address?

If they submit them from personal or anonymous email the patches may have come under more sucutiny.

They gain some trust comming from university email addresses

Re: “They introduce kernel bugs on purpose”

#263
post #226

The 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

I liked this bit, from the footnotes: "Contributors: RWY had the original idea but was reluctant to say it out loud for years. In a moment of weakness, he shared it with MWY and BKN, both of whom immediately recognized this as the best idea RWY will ever have."

Re: “They introduce kernel bugs on purpose”

#265
So I won't lie, this seems like an interesting experiment and I can understand why the professor/research students at UMN wanted to do it, but my god the collateral damage against the University is massive. Banning all contributions from a major University is no joke. I also completely understand the scorched earth response from Greg. Fascinating.

Re: “They introduce kernel bugs on purpose”

#266
post #160

It's funny. When someone like RMS or ESR or (formerly) Torvalds is "disrespectful" to open source maintainers, this is called "tough love", but when someone else does it, it's screamed about like it's some kind of high crime, with calls to permanently cancel access for all people even loosely related to the original offender.

I don't see how this is related. Being rude in tone, and wasting someone's time, are different things. You make it sound like they are the same. But the opposite of what you propose is true. The maintainers are annoyed by others wasting their time in other cases as well as in this case - it's coherent behavior. And in my opinion, it's sensible to be annoyed when someone wasted your time - be it by lazily made patches…

I'm not the one who is making them sound like the same thing. There are literally people in this thread, saying that "wasting time" is being "disrespectful" to the maintainers.

Re: “They introduce kernel bugs on purpose”

#267

The 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…

Thanks for the support.

I also now have submitted a patch series that reverts the majority of all of their contributions so that we can go and properly review them at a later point in time: https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh...

Re: “They introduce kernel bugs on purpose”

#268
There is so much disdain for unethical, ivory tower thinking in universities, this is not helping.

But, allow me to pull a different thread. How liable is the professor, the IRB, and the university if there is any calamity caused by the known code?

What is the high level difference between their action, and spreading malware intentionally?

Re: “They introduce kernel bugs on purpose”

#269
post #253

Greg does not joke around: https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh... [PATCH 000/190] Revertion of all of the umn.edu commits

How does the kernel still run after reverting like this?

I was wondering the same thing. From the Patch itself:

> This patchset has the "easy" reverts, there are 68 remaining ones that need to be manually reviewed. Some of them are not able to be reverted as they already have been reverted, or fixed up with follow-on patches as they were determined to be invalid. Proof that these submissions were almost universally wrong.

Re: “They introduce kernel bugs on purpose”

#270
I did my Ph.D in cognitive neuroscience, where I conducted experiments on human subjects. Running these kinds of experiments required approval from an ethics committee, which for all their faults (and there are many), are quite good at catching this kind of shenanigans.

Is there not some sort of equivalent in this field?

Post reply on HN