[pweissbrod]

"Please provide to the public, in an expedited manner, all information necessary to identify all proposals of known-vulnerable code from any U of MN experiment. The information should include the name of each targeted software, the commit information, purported name of the proposer, email address, date/time, subject, and/or code, so that all software developers can quickly identify such proposals and potentially take remedial action for such experiments."

That sounds more than reasonable as a request to make amends.

The article said that finding all this code is a real problem. If UMN and the students involved are contrite that should be easy to fulfill.

[dylan604]

I love this tactic. To me, if this was an actually controlled experiment, the last step in the experiment would be to undo the bugs they intentionally created. If they did not, this would definitely be sabotage. Based on that, they should have no problem being able to identify what they did.

It's kind of a catch-22 for the UMN.

[dbcurtis]

Indeed. If UMN can't tell how to undo the damage, then it is intentional sabotage, and should be prosecuted as such.

[squarefoot]

This post might give a hint on where to look to find who would probably benefit from sabotaging Linux security.

https://www.mail-archive.com/[e-mail]/msg12...

[dylan604]

Fiction writers would have a hard time making something like this up. But at the same time, of course this is what happens. It's one of the oldest plays in the book to infiltrate the group you want to subvert, and then make changes from within so it is no longer a threat.

[nine_k]

It's like running an experiment by adding a venom in water supply, with a possible later remedial action of offering an antidote.

They seemingly had some success with the first step, until this was duly noticed.

The experiment itself may be a bad idea, but it's a good, useful wake-up call.

[pweissbrod]

Agreed. It's a cool idea. It's not really computer science as much as a penetration test involving humans and processes.

Of course without any semblance of prior consent it isn't quite sabotage but definitely outside the realm of ethical

[dylan604]

>without any semblance of prior consent it isn't quite sabotage

I don't follow. You're saying you're supposed to tell me you're messing with me in order for it to be considered sabotage? That doesn't make any sense, so you must mean something different than that. The entire point of sabotage is to do it under the noses of those you've infiltrated.

Edit: I think I re-read to get your meaning. You're saying without consent it's bad but not quite to the level of sabotage. Not sure if sabotage requires intent to cause harm, but they full well knew what they were doing was not good. While that might not have been enough to sink the ship, it sure wasn't trying to help it stay afloat.

[bluGill]

I can't think of any way other than what the kernel maintainers are already doing. I doubt those involved actually tracked the information needed separately, and even if they did I wouldn't trust them to have tracked everything.

[nash]

The paper claims they reverted all the patches at the time. Obviously they did not.

[gowld]

How is it "Obviously"?

[fluidcruft]

I actually disagree as it would expose which maintainers accepted these sorts of patches and that can have implications for their reputations and livelihood. Beyond that, this is just "Open Source software can be vulnerable to bad actors (News at 10)".

[yndoendo]

Is it your belief that maintainers should be viewed as automatons, impervious to mistakes, like how many view the service industry?

Maintainers are humans, flawed just like us all, good maintainers choose to accept and learn from their gaffes.

[elliekelly]

But let's also keep in mind these are humans, flawed and all, who were experimented on without permission. Ethical (and consensual) experiments would never reveal the identity of the participants and their exact reaction(s) under the experimental conditions. Just because the experiment started without any ethical considerations doesn't mean all ethical considerations should be ignored with respect to the "data" collected by the experiment.

[fluidcruft]

No, my belief is the IRB would only waive consent if this sort of public disclosure is not allowed. Naming-and-shaming is not a valid research goal. Improper research results in censure and exclusion from the scientific corpus, not full public disclosure.

[loeg]

I don't believe the Linux kernel community would perceive the information in that way. Everyone is vulnerable to this kind of bad faith submission; gregkh and others seem to understand that.

[fluidcruft]

Individual kernel maintainers should probably be able to contact the IRB to inquire whether they were personally enrolled in the study. The IRB may reply to that, or they might ask the study to notify all enrolled participants individually. Those individuals could then on their own publicly disclose the fact that they were enrolled. But I don't see why the general public has any need to know anything and it's unreasonable to make the demand.

[sokoloff]

That's true to a point, but hiding that information is arguably (and in my estimation) worse.

"We better not look for other incidences of this nefarious behavior because it might create a small amount of collateral damage. Better to leave those patches unexamined."

[fluidcruft]

UMN has already said they've opened an investigation?

[sokoloff]

There seems to be transparency value in having a different organization do the investigation than made the original judgment to approve the research.

Maybe there's an "internal affairs" equivalent that we'd trust, but this reads to me like "UMN made an error in approving this research but don't worry because UMN is now going to look into it."

[fluidcruft]

Sure, that's entirely reasonable. But that's not what the Linux Foundation is demanding, apparently.