People here don’t seem to be convinced. There’s a good amount of defense in this letter, so I get it, and it could have been framed better, but ultimately it seems like they learned a valuable lesson and have value to add, so why not let people learn from mistakes and move on? They’ve already been publicly shamed…
Reading this thread I am saddened to see hn apparently conform to the law of maximum offence. We see the least charitable explanation for everything said in the apology because outrage gets upvotes.
Open letter from researchers involved in the “hypocrite commit” debacle
311–320 of 384 posts
Re: Open letter from researchers involved in the “hypocrite commit” debacle
#312There 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
#313to the folks picking this apart word-by-word: all evidence suggests that two of the signatures are natives of china, and the third of india. it is reasonable to credit them with not being native english speakers.
Re: Open letter from researchers involved in the “hypocrite commit” debacle
#314> Thank you for your response.
> As you know, the Linux Foundation and the Linux Foundation's Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community.
> Until those actions are taken, we do not have anything further to discuss about this issue.
Was this letter publicly released?
Re: Open letter from researchers involved in the “hypocrite commit” debacle
#315This 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…
This interpretation looks flawed. You discredit the entire message based on a single word--a very general word whose meaning you pinned to a definition which results in the most negative interpretation--and you also ignore the fact that they explicitly state the damage it caused in the same paragraph. To clarify: I'm not arguing this is a good or bad apology; just that the justification provided here looks flawed. Hu…
Re: Open letter from researchers involved in the “hypocrite commit” debacle
#316To summarize: -they apologize for the three patches in 2020 -they claim asking permission would have defeated their research -they claim the other 200 were legitimate patch attempts (a sample of which were, from my personal reading, from 'innocuous but useless' to 'slightly harmful'). Hard to believe, but plausible.
> they claim asking permission would have defeated their research But surely this proves malice aforethought. If you interact with someone under false pretences to deliberately mislead them, then you are effectively lying to them. In fact, if you are doing so in order to receive something of value from them (such as their time reviewing your code) then it could even be seen as fraud. Did they tell their IRB that thei…
Re: Open letter from researchers involved in the “hypocrite commit” debacle
#317Earlier quoted context omitted.
Just clicking the link is enough to fail? No need to enter private info or execute downloaded files? Either your phising emails are badly crafted or you expect employees to see the future.
Agreed. This is something that made me very annoyed when they did it to us. I know exactly what I'm doing, I know that you can't infect a computer from opening a link unless the attacker possesses a new browser 0-day, and expecting your average employee to worry about new browser 0-days is ridiculous. If it were an obvious phishing URL, like a variation on the company domain, then fine (maybe). But it wasn't.
1. (Windows specific) Opens up a Windows file share, which causes the person to authenticate to the file share, which through PtH/Responder results in their enterprise credentials being stolen.
2. Exploited a XSS or CSRF attack on an internal/management endpoint. Which in turns allows a pivot from external to internal access.
3. Steals a web session, cached password or authentication token, resulting in compromise of employee credentials to be used elsewhere (e.g. reused to access enterprise VPN).
These are just some not-a-browser-0day examples of a single click being game-over dangerous.
Re: Open letter from researchers involved in the “hypocrite commit” debacle
#318There 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 am a Red Teamer and work with companies OK, how do you test SocEng vectors? Do you obtain consent and coordinate with every employee that might be targeted to receive your e-mail? >You also study submitting from yandex, gmail, .cn and other email addresses No, the point was submitting from a known and respectable entity, which might affect the level of scrutiny. They weren't testing a whole patching process, but a…
They weren't, though - their own paper explicitly says they used newly created Gmail addresses for the patches...
"We submit the three patches using a random Gmail account to the Linux community and seek their feedback—whether the patches look good to them."
Re: Open letter from researchers involved in the “hypocrite commit” debacle
#319Earlier quoted context omitted.
But they did not introduce security vulnerabilities as there prevented the bad patches from being merged
Those measures were insufficient, as according to the developers, a number of the bogus patches were merged and had to be reverted.
The "hypocrite commits", according to the researchers' own paper, originated from "random Gmail addresses", and the researchers continue to claim none of those got merged (though since they haven't told us what they were, ...)
The additional claim is that some of the commits not covered by their "hypocrite commits" (and thus, submitted from their UMN addresses) contained security bugs, deliberate or not, and the loss of trust in the researchers is sufficient to justify reverting all of their commits until they can be reviewed.
Re: Open letter from researchers involved in the “hypocrite commit” debacle
#320Earlier quoted context omitted.
Thank you for such detailed response. Can there be ethical possibility (highly remote one) where an study (assuming it is objectively justified) conducted with deception, but without prior informed consent at all. (eg. human subjects will not know that there's time is used for another purpose)
Doesn't this happen all the time? Many psychology studies are done by bringing in test subjects, asking for their consent to be interviewed or tested under the guise of studying X, when in fact the researchers are looking to evaluate Y instead? E.g. I the researcher ask if you consent to spending 30min completing a series of tasks to sort objects by their shape, presumably because I want to study your ability to reco…
Yes, this happens all the time. But note the salient features: (1) the subjects are aware that they are research subjects and have agreed to participate (albeit without full knowledge of how the collected data will be analyzed). They have agreed to be studied, and have agreed that their time may be used in pursuit of this research. (2) All such studies undergo a very stringent ethical review and are usually monitored closely by third parties (at least since Milgram made it extremely clear that this was a necessary policy). These issues are complex and difficult to navigate---which is precisely why we have review boards. Every experiment has to be evaluated to balance the requirement to act ethically with the value of the research data to be collected. Skipping that requirement is unacceptable.
In my experience, the moment a research team starts looking for reasons not to classify what they are doing as human experimentation is the moment when it becomes extremely clear that they need board review.