Hacker News Reader

Comment by iasmseanyoung | Hacker News Reader

I do some maintenance work for the linux kernel dvb and infrared subsystems. I reviewed and accepted some patches from umn.edu addresses. They looked fine to me, however they're all around error handling, which can get pretty tricky with long error paths.

What else can I do than revert the lot?

View on HN

gregkh sent a 190 patch series to revert all of the "easy" UMN reverts, pending review. People are now looking at the patches and saying things like, "that's one OK, don't revert".

There are another 68 commits which did not revert cleanly, in some cases because they were later fixed up, already reverted, or some other patch has touched those lines of code. This will require further manual work.

We basically at this point assuming bad faith for all UMN patches and reviewing them all before allowing them to stay in. (Or if they get reverted by default, someone else can manually apply them after they go through strict review.)

Fool me once, shame on you, fool me twice....

Temporarily banning UMN until they can get their IRB act together makes sense, but wholesale reverting every commit ever made by a UMN e-mail address -- whether affiliated with this research or not -- seems kind of extreme?

I'm not sure how many people here understand this, but the University of Minnesota is quite large, over 50,000 people. That's comparable to the entire population of Palo Alto and is larger than MIT, CMU, and Stanford combined. Jeff Dean is a UMN alumni. I am too. The fraction of this set that is actually associated with the shady research is tiny.

It seems to me like the kernel maintainers are at best wasting a whole ton of their own time on this, and at worst re-introducing a wide range of bugs that UMN contributors had fixed over the years. A real "cutting off your nose to spite your face" situation IMO.

Well, it got the heads of the CS department to finally notice. The preprint of the "hypocrite commit" paper was sent out late last year, and while there was contrversy about that back then, with Prof. Lu admitting that he didn't think it was Human Studies Research (HSR) and so he didn't bother to get IRB approval, the CS department heads didn't do squat. And the UMN IRB said, "Okey-dokey!" after being asked to do post hoc review (which as others have said, a post hoc review should have raised red flags with the IRB right there). It's the lack of institutional response and lack of any kind of instiutional controls which is the most concerning.

And we didn't take any action until another series of suspicious patches started getting sent for review from a graduate student from the same group. At which point, we have a unrepentant professor who has gotten rewarded by a paper at IEEE S&P, and being invited to serve on the PC of the IEEE S&P next year, and an apparently apathetic, toothless IRB at UMN. I can see people criticizing us if we hadn't taken action.

Seems like you might be overvaluing the schools contributions? 50k people is a lot but how many changes were reverted?

My point was more about collective punishment than about the value of the contributions. Unrelated people at UMN that have contributed code to Linux shouldn't have their work thrown away.

That said, there were hundreds of reverted commits and many of them were fixing real security bugs. In particular, the same security researchers that did the questionable experiment has also contributed many real bug fixes.

What a mess, that could be hundreds of hours of work …

>We basically at this point assuming bad faith for all UMN patches

This seems like a gross overreaction to three commits that didn't even make it into mainline. Especially when done for commits years before the "research" was done. But I suppose nobody can miss a chance to let loose a little outrage

There were more than three buggy commits, at least one of which is from this month

Other than the three in question no others were intentionally buggy. https://lore.kernel.org/lkml/YIBMKSovJumS79SR@pendragon.idea...

Best to spend time auditing every commit in the kernel for bugs rather than grandstanding over the commits from one university's members.

They admit newer commits are part of a research effort and were sent with the intent to get feedback, but they didn't actually disclose any of that in the patch description [1]. Furthermore, lots of these patches are at best useless and at worst actively introduce bugs.

It's famously hard to distinguish malice from incompetence, but I don't think assuming bad faith is out of line here.

[1] https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah...

How do you know? These people already attempted to manipulate the kernel maintainers repeatedly, even after being caught. Nothing they claim about their own work can be trusted.

"These people" being every student/faculty member at the University of Minnesota for the past few years?

Reply on news.ycombinator.com