Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

Post reply on HN
Print view View original

751–760 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#751

Post by dang »

bitcharmer wrote: post #685
atleta wrote: post #583

It's already being discussed on HN [1] but for some reason it's down to the 3rd page despite having ~1200 upvotes at the moment and ~600 comments, including from Greg KH. (And the submission is only 5 hours old.) [1] https://news.ycombinator.com/item?id=26887670

This is another example of HN's front page submission getting aggressively moderated for no good reason. It's been happening a lot lately.

Perhaps you've been seeing it more for some reason, or it has seemed more aggressive to you for some reason, but I can tell you that the way we moderate HN's front page hasn't changed in many years.

It's clear to me now that this case was a moderation mistake. We make them sometimes (alas), but that's also been true for many years. Moderation is guesswork. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Re: “They introduce kernel bugs on purpose”

#753

Post by pushcx »

CS researchers at the University of Chicago did a similar experiment on me and other maintainers a couple years ago: https://github.com/lobsters/lobsters/issues/517

And similarly to U Minn, their IRB covered for them: https://lobste.rs/s/3qgyzp/they_introduce_kernel_bugs_on_pur...

My experience felt really shitty, and I'm sorry to see I'm not alone. If anyone is organizing a broad response to redress previous abuses or prevent future abuse, I'd appreciate hearing about it, my email's on my profile.

Re: “They introduce kernel bugs on purpose”

#754

Post by kevingadd »

tcelvis wrote: post #664
gregkh wrote: post #267

Earlier quoted context omitted.

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...

Putting the ethical question of the researcher aside, the fact you want to "properly review them at a later point in time" seems to suggest a lack of confidence in the kernel review process. Since this researcher is apparently not an established figure in the kernel community, my expectation is the patches have gone through the most rigorous review process. If you think the risk of malicious patches from this person…

Not all kernel reviewers are being paid by their employer to review patches. Kernel reviews are "free" to the contributor because everyone operates on the assumption that every contributor wants to make Linux better by contributing high-quality patches. In this case, multiple people from the University have decided that reviewers' time isn't valuable (so it's acceptable to waste it) and that the quality of the Kernel isn't important (so it's acceptable to make it worse on purpose). A ban is a completely appropriate response to this, and reverting until you can review all the commits is an appropriate safety measure.

Whether or not this indicates flaws in the review process is a separate issue, but I don't know how you can justify not reverting all the commits. It'd be highly irresponsible to leave them in.

Re: “They introduce kernel bugs on purpose”

#755

Post by Igelau »

g42gregory wrote: post #731

Reading this email exchange, I worry about the state of our education system, including computer science departments. Instead of making coherent arguments, this PhD student speaks about "preconceived biases". I loved Greg's response. The spirit of Linus lives within the Kernel! These UMN people should be nowhere near the kernel. I guess they got the answer to their research on what would happen if you keep submitting…

The tone of Pakki's reply made me cringe:

> Attitude that is not only unwelcome but also intimidating to newbies and non experts

Between that and the "Clarifications" document suggesting they handle it by updating their Code of Conduct, they're clearly trying really hard to frame all of this as some kind of toxic culture in kernel development. That's a hideous defense. It's like a bad MMA fight where one fighter refuses to stand up because he insists on keeping it a ground fight. Maybe it works sometimes, but it's shameful.

Re: “They introduce kernel bugs on purpose”

#756

Post by dang »

mort96 wrote: post #348

The previous discussion seems to have suddenly disappeared from the front page: https://news.ycombinator.com/item?id=26887670

Edit: actually it was standard moderation but in a bit of an unclear way - see https://news.ycombinator.com/item?id=26894033.

We made a mistake. I'm not sure what happened but it's possible that we mistook this post for garden-variety mailing-list drama. A lot of that comes up on HN, and is mostly not interesting; same with Github Issues drama.

In reality, this post is clearly above that bar—it's a genuinely interesting and significant story that the community has a ton of energy to discuss, and is well on topic. I've restored the thread now, and merged in the dupe that was on the front page in its stead.

Sorry everybody! Our only priority is to serve what the community finds (intellectually) interesting, but moderation is guesswork and it's not always easy to tell what's chaff.

Re: “They introduce kernel bugs on purpose”

#757

Post by temac »

ENOTTY wrote: 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 don't feel sorry at all. If you want to contribute from there, show that the rogue professor and their students have been prevented from doing further malicious contributions (that is probably at least: from doing any contribution at all during a quite long period -- and that is fair against repeated infractions), and I'm sure that you will be able to contribute back again under the University umbrella.

If you don't manage to reach that goal, too bad, but you can contribute on a personal capacity, and/or go work elsewhere.

Re: “They introduce kernel bugs on purpose”

#758

Post by turndown »

gregkh wrote: post #267
rzwitserloot wrote: post #181

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...

Just wanted you to know that I think you're an amazing programmer

Re: “They introduce kernel bugs on purpose”

#759

Post by lacker »

tcelvis wrote: post #664
gregkh wrote: post #267

Earlier quoted context omitted.

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...

Putting the ethical question of the researcher aside, the fact you want to "properly review them at a later point in time" seems to suggest a lack of confidence in the kernel review process. Since this researcher is apparently not an established figure in the kernel community, my expectation is the patches have gone through the most rigorous review process. If you think the risk of malicious patches from this person…

The fact you want to "properly review them at a later point in time" seems to suggest a lack of confidence in the kernel review process.

Basically, yes. The kernel review process does not catch 100% of intentionally introduced security flaws. It isn't perfect, and I don't think anyone is claiming that it is perfect. Whenever there's an indication that a group has been intentionally introducing security flaws, it is just common sense to go back and put a higher bar on reviewing it for security.

Re: “They introduce kernel bugs on purpose”

#760

Post by nkurz »

duncaen wrote: post #221
bluGill wrote: post #213

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

> The IRB of University of Minnesota reviewed the procedures of the experiment and determined that this is not human research.

I'm not sure how it affects things, but I think it's important to clarify that they did not obtain the IRB-exempt letter in advance of doing the research, but after the ethically questionable actions had already been taken:

The IRB of UMN reviewed the study and determined that this is not human research (a formal IRB exempt letter was obtained). Throughout the study, we honestly did not think this is human research, so we did not apply for an IRB approval in the beginning. ... We would like to thank the people who suggested us to talk to IRB after seeing the paper abstract.

https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....

Post reply on HN