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

UMN CS&E Statement on Linux Kernel Research

cse.umn.edu

Post reply on HN
Print view View original

171–180 of 332 posts

Re: UMN CS&E Statement on Linux Kernel Research

#171

Post by Denvercoder9 »

kapp_in_life wrote: post #149
Denvercoder9 wrote: post #131

Earlier quoted context omitted.

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

Re: UMN CS&E Statement on Linux Kernel Research

#174

Post by boomboomsubban »

agf wrote: post #152
boomboomsubban wrote: post #106

Earlier quoted context omitted.

> At any point they can just say "we're still investigating" until enough time has passed people aren't paying attention any more. They need to act to get the ban rescinded, they can't just ignore this issue away.

I agree, that's why in this case (as I say in my post) I believe they'll follow through.

As the pressure is already on them to rectify the situation, there's no need to for an artificial deadline. It adds nothing, but could delay their announcement or force them to publish an incomplete response.

Re: UMN CS&E Statement on Linux Kernel Research

#175

Post by kelnos »

ethbr0 wrote: post #157
agf wrote: post #99

Earlier quoted context omitted.

It is a good statement, and I believe they'll follow through, but it's missing something important that is often missing from otherwise professional communication. The last line is "We will report our findings back to the community as soon as practical." It should be followed by "and we will provide an update in no more than 30 days". Without any explicit time frame, holding them publicly accountable becomes trickier…

> explicit time frame This seems incompatible with the pace of academia, as I have experienced it.

They need not promise to have results in a particular time frame, but they should commit to giving an update by a particular date, even if that update is just, "We've made progress investigating this incident, but we are not yet ready to report our findings. We will give our next update no later than $DATE."

Re: UMN CS&E Statement on Linux Kernel Research

#176

Post by detaro »

a-dub wrote: post #141
a-dub wrote: post #128

Earlier quoted context omitted.

the project is 30 something odd years old now, and is no longer a hobby, it is now critical infrastructure that powers virtually everything. it's unfortunate that something happened in the project that cost the maintainers a lot of hours, that comes with the territory of working on important software, i'd argue. i don't want an espionagetastic fundamentally untrustable and inescapable computing hellscape, airplanes f…

> So you are saying that because a non-controversial method to show the same issue wouldn't cause the publicity connected purely to their way of operating, it was right to ignore the concerns? what's the non-controversial alternative? alerting the organization before they do it? that doesn't work. that's why scientists do blinding and double blinding. if you mean something else, then i'm missing parts of this (really…

To quote my comment above:

> If you wanted to know if the kernel review process is able to reliably catch malicious attempts you literally could have just asked the kernel maintainers and they'd told you that no, review can't go that deep. Or looked at non-malicious bugs and observed that no, review does not catch all bugs with security implications.

> You'd very likely would have been able to get code past them even if you told them that there are attempts coming and got their approval.

If you want to know that the process isn't catching all attacks, that should be all you need. For the second case, getting patches past a warned maintainer is harder and should be even better evidence of the problems of the process, without any of the concerns. There is a wide range of options to learn about code review, and what they did was one of the extreme ends - just to find "yes, what everyone has been saying is true". And then not putting in the work to make amends after it becomes clear it wasn't appreciated, so now this other student got caught in his advisors mess (assuming the representation of him actually testing a new analyzer and not being part of a repeated attempt to introduce bugs is true - the way he went about it also wasn't good, but way less bad).

But you don't get splashy outrage, and thus less success at "raising awareness" with people that didn't care before, which is what your comment seemed to argue for.

Re: UMN CS&E Statement on Linux Kernel Research

#177

Post by kentonv »

tytso wrote: post #78
iasmseanyoung wrote: post #34

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?

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

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.

Re: UMN CS&E Statement on Linux Kernel Research

#178

Post by xwolfi »

detaro wrote: post #9

I found these statements by the associate department head interesting: https://twitter.com/lorenterveen/status/1384955467051454466 > I do work in Social Computing, and this situation is directly analogous to a number of incidents on Wikipedia quite awhile ago that led to that community and researchers reaching an understanding on research methods that are and are not acceptable. and https://twitter.com/lorenterveen/s…

Oh so interesting ! In my french uni, psych teachers were all doing wikipedia research to prove it was unreliable by timing correction delay of purposedly introduced mistakes,

They were so proud of their discovery. They didnt think to time what that would take if they went to a printer and changed the text there before a book is printed.

Re: UMN CS&E Statement on Linux Kernel Research

#179

Post by dmatech »

colechristensen wrote: post #79
mewse-hn wrote: post #8

Earlier quoted context omitted.

I also think it's a good response but I think an apology would be in order - perhaps left out because it can be considered an admission of guilt. The way their statement stands they can investigate themselves and determine they did nothing wrong, we'll have to see what they say down the road.

Apologies are overrated. Are these leaders actually sorry for something they likely weren’t aware of before today? Doubtful. Who are they apologizing to? The public? When the issue has gotten actual attention an apology to the kernel mailing list might be appropriate, but as someone who has been apologized to many times it all just becomes meaningless, who cares if you say you’re sorry. I care what you’ll do about it…

Immediate knee-jerk apologies are usually worthless because the person apologizing usually has no idea what's going on and can't make a reasoned statement. They're just trying to do damage control.

The best apologies are the ones that are done after some reflection, not under duress, and not purely for reputation.

Re: UMN CS&E Statement on Linux Kernel Research

#180

Post by neltnerb »

kelnos wrote: post #175
ethbr0 wrote: post #157

Earlier quoted context omitted.

> explicit time frame This seems incompatible with the pace of academia, as I have experienced it.

They need not promise to have results in a particular time frame, but they should commit to giving an update by a particular date, even if that update is just, "We've made progress investigating this incident, but we are not yet ready to report our findings. We will give our next update no later than $DATE."

I have also seen many times a university happy to throw a student or even a faculty member under the bus, and in this case it seems extremely clear that they were running an unethical sociological experiment that was probably not reviewed by the IRB there. That's grounds for the university very rapidly turning on you.

Violating IRB ethics is a very serious issue, and has timelines in place once a complaint is filed. I expect that this statement was intended to be fast, short, and direct because of the time sensitivity.

Post reply on HN