Live data from Hacker News

UMN CS&E Statement on Linux Kernel Research

cse.umn.edu

131–140 of 332 posts

Re: UMN CS&E Statement on Linux Kernel Research

#131
post #78

Earlier quoted context omitted.

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…

>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

Re: UMN CS&E Statement on Linux Kernel Research

#132

I don't know why, but somehow I am not too bothered by the research itself. Sure, in retrospect, it does not sounds like it was the right thing to do (or the right way to do). But, you know, stuff happens. Instead, what bothered me immensely is the way the PhD student handled that interaction: immediately claiming "bias", "slander", playing "victim", etc... I don't know if he learned such a way to communicate from hi…

Maybe that was in line with the "research"?

I think this can be an interesting topic in itself, how those trigger words and victim playing can get you through code reviews faster. It's certainly true in my company...

Re: UMN CS&E Statement on Linux Kernel Research

#133
post #128
post #93

Earlier quoted context omitted.

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

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? Lots of slippery slopes there, and science has spend a long time to get away from such an "the end justifies the means" attitude.

Re: UMN CS&E Statement on Linux Kernel Research

#135

Earlier quoted context omitted.

Sorry for getting sidetracked, but does cc has any special function here or you are hoping that dang would read all the comments and see your cc?

I think dang might have something in place which alerts him when he is mentioned. Certainly he tends to show up quickly when people "page" him like this.

[deleted]

Re: UMN CS&E Statement on Linux Kernel Research

#136
post #125

Earlier quoted context omitted.

I'm not sure how you get that. The ban is mentioned as part of a single sentence that acknowledges the current state of the situation, which seems obligatory, so of course it's there. Then the whole second paragraph is talking about how they're shutting down the activity that led to that situation while they work on getting to the bottom of it. This seems like an entirely appropriate balance of text and emphasis for…

> 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. > We take this situation extremely seriously. I think it’s because the last bit of the first paragraph – the ban – flows onto the second paragraph – the situation. Once you’ve had the two linked, it’s like one of those ambiguous opti…

> I think it’s because the last bit of the first paragraph – the ban – flows onto the second paragraph – the situation.

So, as long as you ignore the formatting they presented it with and decide to read it without it, you can come to a different conclusion?

I don't think contortions such as that to link sentences is fair, nor the fault of the organization that put forth for a statement specifically separating them.

Re: UMN CS&E Statement on Linux Kernel Research

#138
post #98
post #81

Earlier quoted context omitted.

I’ve read and re-read that statement, and it seems like the ban is the focus – not what led to the ban. I get that they may not know anything, but there are other ways to word that without admitting liability, making it seem less like the focus is on the ban and more on the allegedly shady stuff.

I entirely disagree. Not once do they talk about getting the ban removed, instead they talk about figuring out why it happened and how to be better at having research done being ethical. Was the ban the trigger to them (the heads) looking into it ? Of course since they do already have safeguards and review processes in place, this happened despite those, so they're saying they will investigate them to figure out how…

> Not once do they talk about getting the ban removed, instead they talk about figuring out why it happened and how to be better at having research done being ethical.

I feel as if we’re discussing two different statements.

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

Here the cause is that "the research method used raised serious concerns in the Linux Kernel community"

Not that it was unethical, or potentially how it was. It’s not that something clearly went wrong. The cause can be read as the response, rather than the action.

> safeguard against future issues, if needed

Re: UMN CS&E Statement on Linux Kernel Research

#139

I think everybody is missing the point. If one grad student was able to do this, imagine what a team of dozens of well-paid, well-equipped, and highly experienced security experts could do. In other news, we just learned that any half-decent security agency has already injected their own vulnerabilities and back-doors in OSS.

> do this

They got caught and had all their contributions reverted.

Re: UMN CS&E Statement on Linux Kernel Research

#140
To me reverting those hundreds of patches sounds like an overreaction, which might cause actual damage. It's not clear (at least from what I have read in the thread) that this code, which may be wrong or at least useless, is part of any "let's check their patch process" experiment (or did I just miss that?)

That they did that in the past is clearly unethical and was generally a shitty thing to do, but this group also seems to do technical security research. That the student (allegedly) trusted his static code analyzer so much that he did not care to verify its findings doesn't speak for him, but Hanlon's razor may also apply here. Just banning that student (if he keeps submitting technically inferior patches) should be enough imho.

Post reply on HN