Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open letter from researchers involved in the “hypocrite commit” debacle

lore.kernel.org

Post reply on HN
Print view View original

231–240 of 384 posts

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#231

Post by varajelle »

createdapril24 wrote: post #49

There is a major error made by the research group. It starts and ends here: "we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches." I am a Red Teamer and work with companies to understand how their detective/preventative/recovery controls and processes are working. Here's how you resolve this: You work with maintainers to get t…

> You work out a mechanism to prevent submitted patches from being merged (e.g. maintainers are notified before bad patches accepted by code review processes are merged).

It is my understanding that this happened and that no bad patches were actually merged.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#232

Post by gorgoiler »

juliansimioni wrote: post #91

This apology fails from the 5th word: "We sincerely apologize for any harm..." While there are other requirements, a sincere apology cannot in any way entertain doubt about the fact that there WAS harm. Truly acknowledging the harm done is foundational to a real apology, and most of us (myself included) end up sneaking in weasel words or phrases like this. Psychologically, its nice for the apologizer, since it allows…

That fifth word is a mistake and the apology certainly has flaws, but you are being extreme.

A more substantial criticism is that blending we’re sorry with excuses and mitigating explanations is what makes it lose impact.

But really, they acknowledge the harm they did and they said sorry and I hope you give them some credit for doing so.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#233

Post by varajelle »

akersten wrote: post #161
thanhhaimai wrote: post #154

Earlier quoted context omitted.

"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith." https://news.ycombinator.com/newsguidelines.html I think it's both unfair and non-constructive to pick apart a apology letter based on one word like that. Let's assume good faith, especially when the writer's English might not be their first language (based on their name).

We are talking about deliberate security vulnerabilities in the Linux kernel, a piece of critical infrastructure. Frankly, this is not the place to assume good faith.

But they did not introduce security vulnerabilities as there prevented the bad patches from being merged

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#234

Post by rurban »

So now it gets interesting when the linux maintainers themselves cannot seperate good from bad patches.

It's a 190 vs 3 bad, against ~50 vs 143 bad.

Let's hope the maintainers can correctly identify the good ones, now with the given hints (August 2020 only). Or if they still keep staying in witchhunt mode. Word against word. Some of the latest patches do look wrong, but I'm not an expert. Analysis will need a few weeks.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#235

Post by pcl »

createdapril24 wrote: post #49

There is a major error made by the research group. It starts and ends here: "we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches." I am a Red Teamer and work with companies to understand how their detective/preventative/recovery controls and processes are working. Here's how you resolve this: You work with maintainers to get t…

I agree with the approach you’ve outlined.

I also empathize with the plight of the researchers — Linux is a bit different than normal Red Team engagements, in that a normal organization has a hunch of administrative / management layers who typically do not participate in the operations of the system being tested. A VP of engineering at a medium to large company is unlikely to be committing code, much less maintaining the build pipeline etc.

This is not the case with Linux. The people “at the top” are also reviewers, and so it’s pretty likely that notifying them will result in a change of behavior.

I wonder if there is some way to build some sort of Red Team consent “blind trust” organization, such that willing open source projects could agree to responsible attacks, and the attackers could register their work (including disclosure / mitigation plans) with the blind trust ahead of time.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#236

Post by lrvick »

bawolff wrote: post #115
sombragris wrote: post #24

I really appreciate the apology and as they stated, its unconditional nature. Good. However, I find something very problematic. This quote shows it: "We have learned some important lessons about research with the open source community from this incident." This is something I don't like. This is not something about "research with the open source community". If anything, they should have learned something about treatin…

Imagine if instead they did this research with the closed source community. You know, get hired under false pretenses, sneak some vulns into some commercial product, write a paper about how easy it was. Pretty sure if they tried that they would be in jail right now.

There are literally companies you can hire that will go this far pentesting your company and the employees involved are not in on it.

How else do you prove your process can stop real infiltrators by state actors?

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#237

Post by varajelle »

darawk wrote: post #186
thayne wrote: post #183

Earlier quoted context omitted.

What about the risk to the reputation of anyone who approves these patches? Or of intentinally buggy patches making it into the wild and being exploited?

> What about the risk to the reputation of anyone who approves these patches? This is a risk, but it's exposing vulnerabilities is always preferable to leaving them in place. > Or of intentinally buggy patches making it into the wild and being exploited? There was no real risk of this. They specifically did not allow it to make its way into real releases. If they had allowed it into actual releases, I would have a se…

There is also the risk that a third party sees the patch on a mailing list, and merges it to his internal branch because it looks like it is fixing one of his problem.

But I'd argue it is his own fault to use unsupported patches.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#239

Post by cblconfederate »

sombragris wrote: post #24

I really appreciate the apology and as they stated, its unconditional nature. Good. However, I find something very problematic. This quote shows it: "We have learned some important lessons about research with the open source community from this incident." This is something I don't like. This is not something about "research with the open source community". If anything, they should have learned something about treatin…

This falls under behavioral research. I believe psychologists have solved the problem of how to research that is both blind and in line with ethical standards. All they had to do was ask one.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#240

Post by denton-scratch »

justinjlynn wrote: post #27
rajup wrote: post #8

Earlier quoted context omitted.

Just curious, and I'm genuinely asking as someone who thought the letter seemed well-intentioned: what should they have put in the apology letter?

> We are sorry for the harm we've caused by our unethical experimentation involving members of the Linux community. In accordance with community standards and a desire to avoid benefiting from our ethical failure, we have requested the immediate retraction of the papers and other published work resulting from this unethical experimentation. We are also working together with our institutional leadership to address the…

I'd consider that a pretty good apology, if that were the one they had made. I'd like to see it expressed by the university ethics board, not just by the researchers.

I wouldn't trust those researchers again, not for anything. Free software depends heavily on trust. It's astonishing that it works so well; but if you break trust, it's very hard to repair the fractures.

The legal arrangements around free software are fairly fluid, because there hasn't been much case-law, because there's not much money sloshing around for Free Software developers to pay lawyers. Banning pull-requests from that college is much cheaper than sueing.

I hope the whole uni stays banned until the ethics board issues their own apology.

Then let it go, I say. People make mistakes. We shouldn't blame everyone for the mistakes of a few.

But we have to protect the Linux kernel; billions of people depend on it's correctness.

Post reply on HN