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
UMN CS&E Statement on Linux Kernel Research
131–140 of 332 posts
Re: UMN CS&E Statement on Linux Kernel Research
#132I 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…
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
#133Earlier 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…
Re: UMN CS&E Statement on Linux Kernel Research
#134Re: UMN CS&E Statement on Linux Kernel Research
#135Earlier 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.
Re: UMN CS&E Statement on Linux Kernel Research
#136Earlier 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…
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
#137It sucks that the maintainers have to play cleanup, but at least it will hopefully lead to a positive outcome.
Re: UMN CS&E Statement on Linux Kernel Research
#138Earlier 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…
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
#139I 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.
They got caught and had all their contributions reverted.
Re: UMN CS&E Statement on Linux Kernel Research
#140That 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.