top | item 26955921

(no title)

pweissbrod | 4 years ago

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

discuss

order

dylan604|4 years ago

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|4 years ago

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

nine_k|4 years ago

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|4 years ago

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

bluGill|4 years ago

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|4 years ago

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

gowld|4 years ago

How is it "Obviously"?

fluidcruft|4 years ago

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|4 years ago

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.

loeg|4 years ago

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.

sokoloff|4 years ago

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