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!"
“They introduce kernel bugs on purpose”
261–270 of 1001 posts
Re: “They introduce kernel bugs on purpose”
#262The 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?
They gain some trust comming from university email addresses
Re: “They introduce kernel bugs on purpose”
#263The 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”
#264Greg does not joke around: https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh... [PATCH 000/190] Revertion of all of the umn.edu commits
Re: “They introduce kernel bugs on purpose”
#265Re: “They introduce kernel bugs on purpose”
#266It'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…
Re: “They introduce kernel bugs on purpose”
#267The 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…
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”
#268But, 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”
#269Greg 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?
> 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”
#270Is there not some sort of equivalent in this field?