Live data from Hacker News

UMN CS&E Statement on Linux Kernel Research

cse.umn.edu

251–260 of 332 posts

Re: UMN CS&E Statement on Linux Kernel Research

#251
post #99
post #2

This is a great statement, they confirm they're aware of the issue, they acknowledge the concerns and they set out their intention to gather the full facts whilst suspending the operation of the research in the meantime. They also acknowledge the systematic way the need to deal with this. I hope their follow up is as thorough but I want to applaud this, it's a good approach.

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…

Educational instutions don't generally do that. In many cases, they can't.

Re: UMN CS&E Statement on Linux Kernel Research

#252

Earlier quoted context omitted.

The focus is rescinding the ban, but they acknowledge that the way to do so is review their actions and set up safeguards to prevent similar things from happening. There's too much bureaucracy involved for them to already publicly review their actions.

The entire statement has only 2 paragraphs, and says absolutely nothing at all about rescinding the ban.

Why else would they take the ban extremely seriously and take the actions mentioned? I guess it's possible they're worried about the ban spreading, but rescinding the ban seems more likely.

Re: UMN CS&E Statement on Linux Kernel Research

#253

Earlier quoted context omitted.

And in the meantime allowing patched permissions vulnerabilities to reappear in mainline? Seems to be a bit of an overreaction no? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Except that patch is clearly BS! You can't patch a double-read vulnerability by checking for a capability; that's not a thing that works. So either the description is wrong, or the patch is wrong, or both. And the point of the reverts is that the kernel maintainers don't have the unlimited time that would be necessary to re-review all of these questionable patches for probable malicious underhanded C, so they are rev…

You don't think reverting a patch from someone whose only relation is working(worked?) at the same university as the advisor initially responsible for the security "research" is overkill? If the goal is to prevent security bugs in mainline then maybe haphazardly reverting everything that doesn't conflict and fixing it later isn't the best approach.

I'm disappointed at seeing hackernews jump on this mindless mob justice like other sites would.

Re: UMN CS&E Statement on Linux Kernel Research

#254

Earlier quoted context omitted.

He is an adjunct that just trashed university's reputation. I'm sure it would even fall into firing for cause

He's not an adjunct. https://www-users.cs.umn.edu/~kjlu/ Adjuncts don't have Ph.D students.

He is not tenured and until he is he is basically an adjunct.

Re: UMN CS&E Statement on Linux Kernel Research

#255
post #249
post #153

Earlier quoted context omitted.

They’d be concerned about (known-ish) bad actors getting commits into Linux without anyone catching it, and probably want to tell the foundation to start red-teaming the kernel commit process.

What's the source of your information that some US government agency has control and/or influence over Linux developers? Also in this case, what makes "US" special? Your comment sounds like American exceptionalism all over to me.

> What's the source of your information that some US government agency has control and/or influence over Linux developers?

(I'm not the user you're replying to.)

Nothing, frankly. But why can't any agency tell them that red-teaming is a good idea? DHS Cybersecurity is interested in keeping Linux secure, so it will tell them.

There's no "American exceptionalism" in the parent comment, just that the US is a pretty influential country and it may want to give its opinion.

Re: UMN CS&E Statement on Linux Kernel Research

#256

Earlier quoted context omitted.

The story just broke . We don’t know what the IRB saw, we don’t know what they said. Throwing anyone under the bus before there any time to even start asking questions is not what any smart administration should do.

We know that they approved the research.

I think it’s more accurate to say that “we know that they approved something. Whether or not that something turns out to be exactly that this professor and his student did here is I gather a different question.

Re: UMN CS&E Statement on Linux Kernel Research

#257

The university's ethics committee approved the research, and it was guided by a number of their professors. I see no acknowledgement of this in the statement; instead, I see the groundwork laid for hanging the students out to dry. > The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel. Th…

I think it would be important that the students are punished no more harshly than the professor.

Re: UMN CS&E Statement on Linux Kernel Research

#258
post #219

Earlier quoted context omitted.

It is a good PR statement, but it doesn't touch on any of the Linux Kernel community's concerns. It makes no committment to working with the community or, like you said provide any kind of explicit time frame. Instead, the statement is there to prevent journalists from putting "UWN puts the entire internet at risk" on their front page. Instead, it frames the incident into a boring "Students offended the Linux Kernel…

Well put. It’s taken me the last hour to realise that it really is refreshingly transparent. To me, it’s like the distinction between offence caused and actually showing some genuine reflection as to why there might be offence caused. This statement, to me, is firmly in the former camp.

This statement is in the former camp, stating that they do not have enough data yet to be able to be in the latter camp. They're stating that they'll be working toward it. It's a statement that they needed to put out asap before being able to state affirmatively what actually happened, since that can take time.

Re: UMN CS&E Statement on Linux Kernel Research

#259

Earlier quoted context omitted.

> respond with decisive action afterwards. Not the other way around. ... absolutely. Perhaps people liked the flavor.

Your insinuation that I think there may have been no wrongdoing is unjustified and insulting. The behavior has been halted from both sides, no more active harm is being done; your urgency is misplaced. Somehow you think it's unreasonable to investigate before casting judgement -- as if justice itself is invalid if not met out at the pace of a twitter mob's attention span.

I beg your pardon; i do not insinuate anything on your part: I agree with you. Investigate this and see if there's been any wrongdoing or just honest mistakes and correct those that were made... at the professional, academic level; that certainly seems proper.

I am snarking about the apparent disconnect between the previous suspect activities that have apparently not yet resulted in that kind of oversight thus requiring this kind of sanction from the kernel team. I am snarking because the "poor us" these folks already pulled on LKML shows any debate is pointless, as this is firmly a matter of identity politics already.

In other words, yes, some people do prefer that flavor.

Re: UMN CS&E Statement on Linux Kernel Research

#260
post #175
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."

My experience with anything that involves other faculty (at worse, tenured faculty) is that it will get done some time between later and never. With prioritization slipping the further you venture from your home department.

And this is by definition a matter that will involve a lot of parties. At minimum, as everyone in the chain tries to ensure their ass is covered and how it's not really their fault, because it wasn't really their job to say no to this.

Post reply on HN