An Update on the UMN Affair | Hacker News Reader

An Update on the UMN Affair

lwn.net

462 pointschmaynard294 comments

I totally agree this is a very balanced review of the affair.

The fact that "kernel maintainers ... are overworked and do not have the time to properly review every patch that passes through their hands" is not a situation created by the group of researchers.

If the Linux kernel is so crucial to the real world industry, and the kernel team is so distressed at their work, this is a problem need to be seriously addressed. Proactively punish the whole UMN does nothing to address the real issue here.

If the team is so distressed at this tremendously important work and they constantly feel they are on the edge of collapsing, may be you really really really should ask for outside help and even demand more contributions from the big techs.

Nobody should overwork, especially those work on something so crucial to the whole industry.

Edit: I just read a line from the Rust Foundation page [1]: "Good software is built by happy, well-supported people."

1. https://foundation.rust-lang.org/

> Proactively punish the whole UMN does nothing to address the real issue here.

Sorry, but academics using the presumption of good faith that their status brings to do black/gray hat security work using an open source project of critical social importance as a dupe is a very real problem on its own. And it absolutely requires a separate solution. Other academic fields treat research ethics as critically important. Something like would simply end the career of someone in medicine, for example. Maybe computer science should too.

That the public kernel maintainers need more support and resources is a problem also. But the solution is different. We should be willing to discuss both and not use the latter as a way to make excuses for the nutjobs at Minnesota.

Publishing sting is not the UMN team's intervention. The Sokal affair [1] is probably the most famous one. There are many others too [2]. In the Grievance studies affair [3], three researchers submitted 20 fake articles. They must have wasted tons of works on review teams.

1. https://en.wikipedia.org/wiki/Sokal_affair

2. https://en.wikipedia.org/wiki/List_of_scholarly_publishing_s...

3. https://en.wikipedia.org/wiki/Grievance_studies_affair

There's a big difference between a publishing a fake article and trojaning the kernel.

Not in terms of the reviewers time.

The Linux kernel is infrastructure. If it has bugs or security flaws, that directly impacts people’s lives.

Intentionally publishing pseudointellectual nonsense in a journal of pseudointellectual nonsense by wasting the time of peer reviewers in pseudointellectual fields of study does not have any direct effect in the real world. The stakes are simply not comparable. To be blunt, even the value of the reviewers’ wasted time is not comparable.

Sokal and Pluckrose-Boghossian-Lindsay were polemics against misguided academic practice, you can make a case that these were piss-takes, not research projects.

Note that there were real-world repercussions against Boghossian from his institution.

Isn't the idea that bad faith actors will always tell you they're acting in good faith?

The researchers should be banned from contributing, but the Linux maintainers shouldn't be assuming all contributions are in good faith. Both things can be true. Trust but verify.

> the Linux maintainers shouldn't be assuming all contributions are in good faith

They don't. The kernel has been under threat for a very long time. Here's an example from 2003: https://lwn.net/Articles/57135/

By banning the University, they bring attention to the proper authorities and light a fire under them to resolve the issue. The IRB should not have allowed this to happen. I've worked in the academic survey industry and there are strict rules you must follow with human subjects. Last I heard, the kernel team was still mostly human. You don't get to secretly do things to your subjects.

I believe even the old Folger's commercials where they secretly replaced people's coffee with Folger's Crystals would not pass muster with respect to informed consent.

Oh yes I completely agree UMN deserves the ban. The code review process for Linux kernel commits clearly needs to be improved as well. Hence "both can be true".

Did you read the LWN article and the TAB statement?

> The writing of a paper on this research [PDF] was not the immediate cause of the recent events; instead, it was the posting of a buggy patch originating from an experimental static-analysis tool run by another developer at UMN. That led developers in the kernel community to suspect that the effort to submit intentionally malicious patches was still ongoing. Since then, it has become apparent that this is not the case, but by the time the full story became clear, the discussion was already running at full speed.

and

> The LF Technical Advisory Board is taking a look at the history of UMN's contributions and their associated research projects. At present, it seems the vast majority of patches have been in good faith, but we're continuing to review the work. Several public conversations have already started around our expectations of contributors.

The recent shit storm was not caused by a malicious act on the part of anybody at UMN. The "overworked" maintainers made a mistake and ascribed malice to the actions of a good-faith contributor who also happened to be from UMN.

I still see people in this thread assuming that UMN has some history of submitting malicious patches and the wholesale ban is a justifiable response. That response might be justified if some internal ethical system at UMN is broken, but that is not the case, at least here. This history is clean save the one incident regarding the research paper, which has been withdrawn.

> The recent shit storm was not caused by a malicious act on the part of anybody at UMN. The "overworked" maintainers made a mistake and ascribed malice to the actions of a good-faith contributor who also happened to be from UMN

This is not true and is explained in the article:

> That said, there are multiple definitions of "malice". To some of the developers involved, posting unverified patches from an experimental static-analysis tool without disclosing their nature is a malicious act. It is another form of experiment involving non-consenting humans.

This is the “recent shit storm” and can in no way be described as “good-faith” particularly after the disgusting response from the researcher after being called out on their shit.

This is so very frustrating, and why I wish the LWN article more strongly explained how wrong Greg was.

> particularly after the disgusting response from the researcher after being called out on their shit.

The researcher was slandered publicly by Greg. Greg repeatedly accuses the maintainer of purposefully submitting malicious patches, which he NEVER did. Greg also does so in an extraordinarily insulting way, diminishing the student's skillset, somewhat ironically as the student's research did in fact find bugs in the kernel.

The researcher very rightfully responded the way he did - by calling out the slanderous remarks and removing himself from the Linux Kernel, a project that will no longer benefit from his contributions (which, if you bothered to look into, are far better than Greg gave credit for).

Greg is very much in the wrong here. He is the one who made repeated false accusations.

Please do not continue the very unfortunate attacks against a student who was only trying to submit good-faith patches to the kernel.

You omitted the fact that Aditya's advisor was Kangjie Lu, who ran the research project with the bogus patches. It would be natural to assume that anything from that general direction would be more of the same.

I didn't "omit it", it's irrelevant. It obviously would not be natural since it was incorrect, and a natural response would not be to throw blind, incorrect allegations and ridiculous insults due to a suspicion.

Greg overreacted. Linus agrees, other kernel maintainers agree. The only person who won't come out and admit it is Greg himself, and his overreaction has cost the kernel a valuable asset as well as the reputation of an innocent researcher, who now gets comments like "they're disgusting" from people who took Greg's accusations at face value.

So, there is a code of conduct..

https://www.kernel.org/doc/html/latest/process/code-of-condu...

Yes, it's a sham, Greg is on the CoC committee.

And this justifies slandering another unrelated human how? It might explain the more aggressive jump to an assumption of malice, you are correct, but it sure as hell doesn't justify arbitrary negative actions especially towards another honest human being resulting from such a leap. That's either Greg's fault or Kangjie's fault or some combination but certainly not Aditya's fault and they don't deserve to be treated as sub-human because of simple proximity.

That type of reality is not natural and it's not human and it's not the one I live in.

Be pissed at the stupid research paper all you want. It doesn't justify treating some tertiary human like utter shit.

And for the record nobody is trying to "cancel" Greg or the kernel here. The project is great and Greg is probably a super chill dude on most occasions. But people aren't perfect and fuck up. You can act rashly under stress and later be wrong. That's understandable and that is human. The whole point is how you respond in light of new information. That's the test of character.

We don't need to sit here and sweep Greg's BS under the rug because he's a kernel celebrity. I honestly think some form of apology would go a long way to rectifying the slander, and cool down the whole thing and most importantly, might be enough to make Aditya feel welcome again in the community. Greg was wrong, his behavior rash, and the example should not be emulated by others in our community. Period.

Aditya decided to join a supervisor with questionable ethics who ran a very ill-conceived research project. He could have chosen someone else for his thesis or spoken up when the paper went for submission, or at least stepped aside from kernel development but instead decided to dig in. It's all very poor judgement on his part, in multiple instances. There's no need to normalize that behaviour, because it's not normal, at least not in the world I'd like to live in.

Recommended reading: All Hallows Eve by Charles Williams, a meditation on where stupidity and selfishness lead.

I don't necessarily disagree about how a student should handle an ethically grey situation. But that still doesn't justify treating other humans like shit.

And for the record I don’t think there is even level headed consensus formed yet on the whole paper thing. It’s arguably unethical, but it is also arguably simply inconsiderate. And it has certainly provided some degree of utility, although it’s unclear how much. I think most of the impressions have been molded by Greg’s response during the “kernel peeps are pissed” phase of the whole affair.

And for the record I don’t think there is even level headed consensus formed yet on the whole paper thing.

The paper has been withdrawn because consensus is clear: for experiments on human subjects informed consent is required in advance. The institution recognizes that much: "We acknowledge our responsibility to do this to prevent situations like this incident in the future."

It's also reactionary. There was social pressure and the threat of being perma-banned as an institution from contributing to the kernel. The decision was made under duress. It's not surprising it was withdrawn.

> for experiments on human subjects informed consent is required in advance

By such simple logic A/B testing is unethical. And that may be the case. Still, it's not exactly clear in this case where to draw the line and who/what the subject is.

There's a comment elsewhere in this thread that sums the situation up better than I can: https://news.ycombinator.com/item?id=26985631. I've read the paper and honestly I have a mixed impression. It certainly is respectful and doesn't come off as "we're going to be super malicious and mega waste everyone's time and fuck with the kernel maintainers for fun and science". It does not aim to experiment with humans in order to study how humans socially react to a breach of trust in a high trust collaboration. That was not their goal at all. Arguably, as laid out pretty explicitly in the paper, the experiment is not on human subjects but rather on a system of collaboration used primarily by open source projects. It happens that the system is operated by humans. Are you testing the humans, or stressing the system?

Is making crafted investments in the market for the sole purpose of studying the validity of a hypothetical model unethical? Is it research on humans because the market is a human endeavor operated by humans? These are genuine questions.

There are also different ethical frameworks. No harm was caused by this research. In fact, the only real harm to humans has been Greg berating a person (because of their proximity to past research and perceived sloppy patches) who offered legitimate patches some of which actually fixed bugs in the kernel. Clearly Greg didn't even take the time to understand the patches he just categorically dismissed them all because he had a bone to pick. Now the kernel is down a contributor who's contributions clearly have utility.

Back to the paper, even if it presents the obvious for people working on open source projects, it, like is the status quo in security research, is the working example of the exploit. In my experience people don't give a shit about perceived vulnerabilities until they become real vulnerabilities. As a kernel user, I actually value this research more than the alleged waste of time it may have caused for maintainers. I'm not the only one who feels this way. Sometimes to effect change you need to light a fire under somebody's ass.

So the paper is valuable to some subset of people. It provides utility. It did no harm to computer system or humans. You see what I'm getting at.. there are ethical frameworks under which this paper is clearly ethical (even if you concede it directly and explicitly aimed to experiment on humans, which I debate). Ideally the researchers would have asked Linus and Greg if they could perform the research on their project so they wouldn't feel out of the loop and attacked/culpable when the research was published. I do hope everyone's learned their lesson in that regard.

Anyway back to Greg, you're really moving the goal posts. We can agree 100% that the paper is unethical. The fact is simply irrelevant when considering whether it's right to piss on some student at UMN who presented valid albeit sloppy patches to the kernel in a gesture of good faith in order to try and improve the state of security. It's a breach of the kernel's own community guidelines, at the very least!

This is a ridiculous judgment from someone who has barely a glimpse into someone else's life. You've extrapolated, from a mere association that you know virtually nothing about, that Aditya must be both stupid and selfish.

From his posts to the mailing list it's clear that Greg was aware of the "hypocrite commit" paper and that there was some agreement in place with the University which must have stipulated "no more bogus patches". Professor Lu and everyone in his group were aware of the state of affairs. Then Aditya went and posted another bogus patch, the output of his static analyzer, to further his career, even though he should have known how that would be received. I regretfully stand by my assessment.

You're pulling all of this out of thin air.

> and that there was some agreement in place with the University which must have stipulated "no more bogus patches"

This is baseless.

> Then Aditya went and posted another bogus patch

Not bogus. Aditya's analyzer did in fact find plenty of bugs - do your research, this is confirmed by many other maintainers.

> to further his career, even though he should have known how that would be received

Why should he have known that? I would never expect to receive the kind of feedback given by Greg, followed by a total university ban, over a student submitting subpar commits. It's an insane overreaction.

Greg wrote: "we will have to report this, AGAIN, to your university..."

There was behind-the-scenes talk that the student chose to ignore, it's impossible to interpret in any other way.

Here's another interpretation based on the facts we know today:

Greg was assuming these were patches coming from some new "hypocrite patch" project at UMN and "AGAIN" refers to the previous incident in Aug2020 regarding the paper. I don't think the student was ignoring anything. Greg categorically dismissed legitimate contributions to the kernel because of his rash perception that UMN was up to no good AGAIN. So that's why he referenced the previous event and said AGAIN.

In reality, this isn't some conspiracy where UMN was attempting to add hypocrite patches for a 2nd time. Greg was dead wrong in that regard. You need to read: https://www-users.cs.umn.edu/%7Ekjlu/papers/full-disclosure.....

In other words: Greg and all the other kernel maintainers were made unwilling participants in a research project (the "hypocrite patches") and then were made unwilling participants in another research project with the same advisor (the static analyzer which was of questionable utility).

So - no more free research support for the University of Minnesota. That's fair because the reviewers did not choose to spend time on the University of Minnesota's research output.

> Not bogus. Aditya's analyzer did in fact find plenty of bugs

But the commit in question was bogus, and it looks like Aditya did not properly check the output of his tool. Maybe he did not send bogus patches on purpose, but the fact that he used the Linux kernel as a playground for testing his experimental static analysis tool (without disclosing it in the commits) is still problematic and he should be called out for that.

> And this justifies slandering another unrelated human how?

Are you saying that Aditya was not involved in the hypocrite commits research? He’s not cited in the paper but his name is on the open letter [1].

If this is the case, would you please provide a citation? I feel like I’m missing something or being misled.

[1] https://lwn.net/ml/linux-kernel/CAK8KejpUVLxmqp026JY7x5GzHU2...

Yes, I am saying that, and I don't know what "proof" you want? He isn't cited in the paper, he didn't work on the research.

But here you go if you want to read more about the research. You'll notice that the messages/ patches are all attributed to those cited in the paper.

https://www-users.cs.umn.edu/~kjlu/papers/full-disclosure.pd...

And yes, you are being misled. That's why Greg needs to publicly retract his accusation and apologize. That's why it's so frustrating that LWN did not clearly explain that Greg was flat out wrong.

I can’t understand why he would put his name on that open letter and remain quiet. For now, I will withhold judgment either way and hope more details emerge.

Edit: To clarify, I don’t think you’ve made enough of a case to prove Aditya’s innocence or justified your attack on Greg.

Exactly! This is the "find out" part of "fuck around and find out". Kangjie Lu's research group is permanently tainted.

I don’t appreciate being told what I can and cannot say in this manner. As for attacking people, you’re doing a whole lot more than me, which unlike you, wasn’t my intent.

> I don’t appreciate being told what I can and cannot say in this manner.

I didn't tell you what to say, I'm pleading with you and everyone else to stop spreading misinformation that is costing an innocent man his reputation.

> As for attacking people, you’re doing a whole lot more than me, which unlike you, wasn’t my intent.

You called Aditya's response "disgusting".

I don't see any attacking. Don't be hysterical. I see a plead to yield to facts and to treat other humans with respect because they're human and they deserve basic respect.

> The IRB should not have allowed this to happen.

I see this repeated, but arguments like "You don't get to secretly do things to your subjects." are not sufficient nor is "it's arguably the most important software on the planet". These viewpoints are not agreed upon or codified anywhere that would affect an IRB decision.

"human subjects" qualification -> https://www.fda.gov/about-fda/center-drug-evaluation-and-res... (et al sources)

The notable history of outrage in some communities (did this make the evening news anywhere?) that has been created, may influence future decisions, at best.

The linked page doesn't say anything about what is and isn't a human subject.

But even so, defining human subjects so as to exclude humans who are subject to your experimentation is absurd on the face of it. Who cares what is codified by whom? Experimenting on unwitting subjects is unethical. I had hoped that by now that would be something that didn't need stating and restating.

> The linked page doesn't say anything about what is and isn't a human subject.

Why you decided that was a claim is your own bias talking. I was pointing out the relevant section. You've tried to raise something that isn't the issue, nor is it a sensible question as you undoubtedly realized (But even so).

Every human in an experiment is a human subject. Glad we got that out of the way.

The issue is what an IRB is looking for in evaluating the ethical feasibility of an experiment.

> Experimenting on unwitting subjects is unethical

> I had hoped that by now that would be something that didn't need stating and restating.

That's because it's your opinion. Seriously, go tell your local Target or College Bookstore to stop playing with the wall colors because there is no disclosure AND they make money off of it.

To quote the department [0] as was linked elsewhere:

> An IRB evaluates “Human Subjects Research”, which has a precise technical definition according to US federal regulations (see 45 CFR 46.102), and this technical definition may not accord with intuitive understanding of concepts like “experiments” or even “experiments on people”.

[0]: https://drive.google.com/file/d/1z3Nm2bfR4tH1nOGBpuOmLyoJVEi...

>Something like would simply end the career of someone in medicine, for example.

Not so at UMN!

https://en.wikipedia.org/wiki/Death_of_Dan_Markingson

The physician at the center of it is still employed (as a physician) at UMN.

Thanks for linking to that. I’d never heard of that case before; that is so incredibly horrifying. They should be in jail right now for having a known psychotic patient sign an “informed consent” form.

As an aside, there is such a long history of blatant unethical behavior and pseudoscientific medical procedures throughout the entire history of medicine (and especially so-called “public health” - take AZT as one tiny example), that it shocks me that people have this attitude of “oh yeah bloodletting and lobotomies and clitorectomedies and male circumcision as punishment for masturbation were wrong but everything’s fine now and there’s no giant institutional problems with the medical orthodoxy anymore”

It seems like the investigation didn't harp on it much, but honestly I think the biggest issue is the repeated warnings the patient might have been suicidal. I was helping out with data analysis for a psychiatry study that didn't even really involve an intervention (looking at how well vocal properties from daily audio clips predict clinical scales), and it was made very clear how imperative it was to act if we had any reason to believe the patient was at imminent risk for self harm.

So it is crazy to me that they didn't unenroll the patient upon receiving that warning. If a patient threatened suicide in one of their recordings we would have to get in contact with their main doctor ASAP, and this is actually one of the things the IRB was concerned about - if we didn't review the recordings in a timely fashion but patients thought we did, it could mean a suicide threat gets missed that might not have otherwise. Refusing to change the treatment plan of a known suicidal patient because of a research study really is awful.

I wonder is it just coincidence. Or is there more, yet to be uncovered, cases of evil practices of UMN causing serious damage.

I see this spectacle as punishing the UMN IRB which has demonstrated an inability to prevent issues like this occurring in the future.

If any readers have not learned that the trick to inter-organizational progress is to get the right questions into the right ears, now is a good time to look at that concept. You can tell your own people until you're blue in the face that the customer has a very expensive XY problem, or you can buddy up to one of their engineers and have them ask their management chain for Y, at which point the seas part and you have budget to solve the problem correctly.

The IRB's bosses need to be audited, and as far as I'm aware the IRB hasn't volunteered that it was part of this dustup and promised to do anything about it. Which means someone has to make them do it. Which means their boss needs to care. I don't know how universities are organized, but I'm betting that the president/chancellor of the school has hire/fire control over that group. And if not them, then the board. How do you get the board's attention?

More importantly, if I'm a Gatech student and I don't think my university is being ethical about open source, I can make them care by pointing out how UMN got exiled for doing the same sorts of things we are suggesting doing. If UMN just gets a finger wave they'll just shrug and wait for theirs.

The entire point of an IRB is that they have independence from the rest of the institution, so they can make decisions on ethics without coercion.

You're also ignoring that the UMN IRB never said this research was ethical. All they did was compare the experimental parameters to the definition of human subject research they were given. Since no biological specimens or personal information were being collected, they decided it was outside their jurisdiction and not their problem. Also if I recall correctly this evaluation was done retroactively after the experiment had already happened.

That lasts until the IRB embarrasses the University:

https://www.enterprisenews.com/story/news/education/2021/03/...

https://www.bridgew.edu/racial-justice/messages/research-sur...

> is not a situation created by the group of researchers.

As far as I got from various threads on the issue the university has been involved in at least two major time wasters:

* Breaking the trust model and forcing the maintainers to revert all already accepted patches on suspicion alone

* Running a primitive static code analysis tool that got overeager with correcting impossible bugs and not marking the generated patches as such.

> Proactively punish the whole UMN does nothing to address the real issue here.

Proactive? The universities review board signed off on that mess, there is nothing proactive about banning a group of bad actors after the fact.

Proactive probable refers to also banning the 6700 staff, along with the 46000 students, that are not part of the research project from ever contributing.

That staff and student body is governed by the same ethics board that allowed this to happen.

Facebook experimented on people (some might have even been kernel programmers), but Facebook programmers are still contributing to the kernel. Let's not even talk about all the other organisations who have done some pretty unethical things, I mean lots of corporations who have or still are violating the GPL (on Kernel code even) are allowed to continue to contribute to the kernel.

They didn't experiment on the kernel process itself.

And it would be counterproductive to set up the incentives so that people who aren't contributing in the first place can't.

Do you have any examples of companies that are both still GPL violating and still contributing to Linux mainline?

Why is that a problem? Most kernel contributors aren't governed by any ethics board at all!

They probably work for some company and can you imagine the shit storm if it ever came out that Microsofts board of directors signed off on a Microsoft dev. actively submitting vulnerabilities into the Linux kernel?

An IRB and a board of directors aren't remotely similar. UMN actually does have a board of trustees but they've had literally nothing to do with this incident. The senior administration (and the CS&E department prior to the mailing list blowup) never even knew that this research was happening.

Realistically, if a UMN student submits a patch from their personal, non-.edu email address, will anyone notice or care?

> * Running a primitive static code analysis tool that got overeager with correcting impossible bugs and not marking the generated patches as such.

This is not a major time waster. It happens constantly - students everywhere are doing this, and the patches are accepted constantly.

Further, while Greg classified the entirety of the analyzers findings as being useless, he was incorrect.[0]

> The universities review board signed off on that mess, there is nothing proactive about banning a group of bad actors after the fact.

In terms of the researchers submitting malicious patches it was done without edu addresses, which means that banning them solves nothing.

[0] https://lore.kernel.org/lkml/b43fc2b0-b3cf-15ab-7d3c-25c1f2a...

In fact, most of the fixes fit into the bucket of "potentially useful".

> students everywhere are doing this

Which somehow makes it ok?

The Linux team told UMN not to run experiments on the kernel anymore, and then a student comes along and does it again. Given his association with Kangjie Lu, he should have known better.

> Breaking the trust model and forcing the maintainers to revert all already accepted patches on suspicion alone

The kernel developers chose to do that out of a combination of spite and excessive caution. The actual malicious patches didn't even come from UMN email addresses.

> Proactive? The universities review board signed off on that mess, there is nothing proactive about banning a group of bad actors after the fact.

Why does everyone keep repeating this? The IRB declared that it wasn't human subject research. Tons of other IRBs would have done the same because they all use a standardized definition that hasn't been updated for interactions with online communities.

> Tons of other IRBs would have done the same because they all use a standardized definition that hasn't been updated for interactions with online communities.

I can imagine a paper from the 1940s showing how they checked the security precautions of baby food manufacturers by having a factory worker under their control randomly lace the produced baby food with arsenic to see if the manipulated batches got caught by an "abstract process" before they could enter general distribution.

Yeah, nothing that went wrong in this case can be excused by "but the internets!!!".

In another part of the thread, a commenter linked the response from the department which pointed out that the definition of human subject research and even IRBs themselves are governed by federal statute.

A bunch did go wrong in this case, but the actions of the IRB weren't one of them. They were acting exactly as directed by the law. The fault lies with the researchers who conducted the experiment, and perhaps broadly with the academic community for not establishing guidelines for ethical oversight of non-human subject research.

The definition of human subject is literally "a human a researcher collects information on", as far as I can find the law doesn't even try to over complicate that point. Claiming that researching the Linux review process does not involve human subjects seems to be willfully ignorant.

The letter [0] explains it better than I could:

> Crucially, an essential requirement for research to be considered as “human subjects research” (and thus within the purview of the IRB) is that it involves collecting information about human subjects themselves, such as age, blood pressure, or related. No such information was sought or collected here. [...] Importantly, even if one believed the study did involve human research subjects (perhaps due to the interactions and the incidental collection of email addresses), the study would clearly be exempt from IRB oversight pursuant to 45 CFR 46.104(D).

[0] https://drive.google.com/file/d/1z3Nm2bfR4tH1nOGBpuOmLyoJVEi...

> such as age, blood pressure, or related

So they try to cite the law, giving the relevant section, but the law contains a generic "information or biospecimens" instead of restricting itself to the clearly medical subset they provide. It would be better if they actually cited a source or the exact paragraph that results in their interpretation, because I can't find it.

Even worse they give 46.104(D) as reason why it would be excluded anyway. That is literally the list of all possible reasons something could be excluded. Which of the reasons listed do they refer to?

Maybe it doesn't fix the underlying issues of overworked maintainers, but what the "hypocrite commits" team did was definitely wrong.

I mean, a hacker breaking into a bank for research without explicit permission (i.e. contracts signed etc) would results in prosecution. You don't pull a stunt like that.

According the researchers they never actually committed any "hypocrite commits". If that is true, in your example it would accusing someone of a crime for discussing how to break into a bank for research

From the article:

In response, the UMN researchers posted an open letter apologizing to the community, followed a few days later by a summary of the work they did [PDF] as part of the "hypocrite commits" project. Five patches were submitted overall from two sock-puppet accounts, but one of those was an ordinary bug fix that was sent from the wrong account by mistake. Of the remaining four, one of them was an attempt to insert a bug that was, itself, buggy, so the patch was actually valid; the other three (1, 2, 3) contained real bugs. None of those three were accepted by maintainers, though the reasons for rejection were not always the bugs in question.

So three submissions were malicious and buggy.

There appears to be a disconnect. Their FAQ says otherwise.

> We did not introduce or intend to introduce any bug or vulnerability in the Linux kernel. All the bug-introducing patches stayed only in the email exchanges, without being adopted or merged into any Linux branch, which was explicitly confirmed by maintainers. Therefore, the bug-introducing patches in the email did not even become a Git commit in any Linux branch. None of the Linux users would be affected. The following shows the specific procedure of the experiment. [1]

https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... [1]

My understanding from the LWN article is that the patches were rejected by the maintainers, not that the authors pulled them after passait review.

Lacking informed consent from the kernel mgmt (i.e. G K-H), or external academic oversight, we can't be certain what they planned; I can't see why they deserve the benefit of the doubt.

CS researchers need to catch up with life sciences: pre-registered research, trials plans, external ethical oversight by experts in the technology and ethics.

That only states that no commits were made. The text I quoted states that malicious patches were submitted, but were rejected (ie not committed).

Burnout is a very, very real problem for volunteer organizations in general.

There's also a middle ground where you are doing the most you can sustain. If you run a volunteer group where everyone thinks "I could do more" all the time then there are a lot of missed opportunities.

However, when everyone thinks, "I can't do any more", then any additional insult on top of that becomes a much bigger deal, because it is now 'too much'. For the group's sanity you probably want some fraction to feel underutilized at all times. When 'too much' happens, they get an opportunity to do more, and that extra effort is immediately appreciated.

But even then, sooner or later you'll have two or three dramas that overlap in time and energy and people will get grumpy. Has the kernel team been dealing with some other bullshit this last year? I mean, besides participating in the epidemic with the rest of us, which counts as at least 2 dramas. I think right now you still have to cut people a little slack for getting upset about things you think they shouldn't.

I wish I could just start reviewing random patches that get submitted/accepted into linux, but it's a daunting task. Although I'm good at C, lacking good knowledge of the according subsystem in the kernel makes it impossible to find anything but very trivial errors, which usually get caught by static analyzers afaict. I'm afraid of introducing noise that costs maintainers even more time, by commenting that something might be wrong because "I think you cannot sleep here" or "I think this needs to be in the critical section" when I'm not 100% sure.

The sad thing is that the Linux kernel isn't a small simple project, which manifests in many ways. I once debugged and fixed an issue in i915. Finding out where exactly the patch should go, which repo and branch it should be based on, how to format the commit message, etc took at least twice as long as finding and fixing the issue. You end up in some doc listing instructions for a dozen mail clients to configure them so they don't fuck up your patch when you send it. I guess that's why there is "git send-email"; at some point it was easier to add email sending capabilities to freaking git than to deal with email clients, because the whole process is so archaic. I wonder how many people get discouraged by this whole process and just give up. I'd like to think it's just filtering out low effort contributions, but I'm not really sure.

Long story short, I think the approachability of the Linux kernel is pretty low and I believe there are a bunch of capable people who'd happily get involved in some way, but are discouraged by the high bar of entry. It's a far stretch from github pull requests and issues usability-wise.

>the real issue here

One phrase that always drives up the wall is "the real issue here." There can be more than one issue. For anything complicated, there are going to be at least two issues at hand. Banning a University to get the attention of leadership to corral their research department is a valid response to one of the real issues here.

I don't see the university here is a real issue. Sting research is always uncommon, naturally it won't happen in many years (or ever). It's not like if you don't ban UMN, someone else from their CS department will do another sting on the Linux kernel...

What is far far more important is the overwork problem of the kernel team. And malicious attack from bad actors is way more important threat than a improper research study.

It's a known problem, but getting kernel maintainers up to speed is Not an easy job.

Why are you presuming that the problem of trust would be solved by having more paied developers involved ? Usually a problem of trust is solved by having less people involved

How about the jokers at UMN make an effort to “help out”? Sheesh. If the publicly funded universities can’t lend a hand or do their fair share, what hopes have we that big tech will come in and save open source. Do the universities have money problems?

> Proactively punish the whole UMN does nothing to address the real issue here.

The real issue here is human experimentation without consent or even information. Why do they think they can run experiments on free software developers without even contacting them about it?

I am not sure if you by more contributions from the tech world means donate more money, or donate more patches / fixes etc.

Big tech adds a constant stream of features / extensions to the kernel for some fairly obscure factors that are important if you are a big enterprise or cloud company but matters very little to regular people and regular companies.

If you mean bigger monetary investment I agree. With the exception that with large donations come strings attached.

Key takeaway from this update:

One final lesson that one might be tempted to take is that the kernel is running a terrible risk of malicious patches inserted by actors with rather more skill and resources than the UMN researchers have shown. That could be, but the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more.

Instead of submitting patches with known bugs, the UMN researcher could have done a retrospective study of patches from other kernel developers containing bugs that were later found and fixed. Not only was he acting in bad faith, he was stupid.

There was also a high degree of arrogance on his part. That he thought his needs and priorities outweigh those of the much, much bigger community and/or that he doesn't need permission from anyone in charge of the codebase is just astounding.

That is not considered high impact by the research community ;)

Alternatively, I think the research could be done in an isolated experiment environment among consented participants. For example, they could ask maintainers to review some set of patches outside the context of Linux kernel. They would then ask maintainers opinions on the said patches using some form of questionnaires. If the participants are well informed the nature of the experiments, there would not be any ethic concerns. For incentive, the researchers could pay for any maintainers willing to participate the experiments.

The researcher also could have coordinated with Linux and other Linux leads, so they know which patches will be "bad". They all want the Linux review process to produce high quality code and could have suggested other ways to test the process.

This seems ideal, but Linus would probably have accurately pointed out that it's already well-known that it wouldn't be hard for a malicious actor to insert bad code, so there's nothing really to be learnt here, at the cost of wasting the time of reviewers who are already overwhelmed.

Only looking at patches that were later found and fixed would not be measuring the same thing as what they were doing.

Not saying what they were doing was in any way ok, but I do doubt there's any way to measure what they were trying to measure without deliberately introducing bugs into some sort of review stream. Merely using observational data would produce results that are approximately as useful as those of every other observational design. (to wit: not very)

If you're filing a patch with a pattern you think will get by the review process, why not look to see if that pattern already existed in the code? That would give you the same information and you're potentially uncovering zero days instead of creating them, assuming those issues haven't already been fixed.

> the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more.

Dmitry Vyuko[0] estimated in 2019 that each kernel release contains >20,000 bugs. As an outsider looking in, it seems that the kernel needs a lot more boots on the ground focusing on maintenance.

[0] https://www.youtube.com/watch?v=iAfrrNdl2f4 ~0:00-3:30 for statement.

20,000 NEW bugs?! Or is it the same 20,000 that keep being brought along every release?

I don't know if 20,000 is a large or small number for a codebase the size of the linux kernel. How about bugs per line of code? In Code Complete, Steve McConnell writes "Industry Average: about 15 – 50 errors per 1000 lines of delivered code" As of 2020, there were 27.8 million lines in the kernel git repo. By McConnell's measure, the number of bugs in the kernel is rounding error.

> As an outsider looking in, it seems that the kernel needs a lot more boots on the ground focusing on maintenance.

Following kernel development a decade ago, that was exactly my opinion as well. Maintenance of older, creakier stuff gets little attention. Adding shiny new buggy features was all the rage. Code and architecture review was spotty at best, and a lot of shiny new things caused damage to old things, but no one cared because the new things were shiny.

I feel like I've had this conversation at work at least a few times. It's the ratio between new code and maintenance. Can you solve this by adding more maintainers? Yes. Can you solve it by reallocating people to maintenance? Maybe (depends if they decide to quit instead).

But you can also flip it and ask if this feature focus is really helping or hurting. The parts of the work that look like 'feature factory' work should be treated as suspect. On some projects that can be half of the new work. We get so consumed trying to figure out if we can do something that we don't stop to think if we should.

In a volunteer organization, however, you have to create a certain amount of busy work in order to make sure that new volunteers have stepping stones to becoming bigger contributors. Did this need to be done? No, but we needed a way to get Tom from point A to point C, where we really need his help, and so we had him do B even though it's not really much of a priority.

I assume this is happening already; I would expect nation states to have already inserting a number of exploits so they are prepared in case of war, to exploit the enemy's servers.

This just made me think, I wonder if there is some sort of Trident nuclear warhead submarine equivalent in cyberspace. Software based mutually assured destruction.

I said that on the first post but yea people kept screaming "ethics" "ethics" haha as if apt groups gave a single fuck about your ethics

If UMN is not an APT group, then it is reasonable to expect them to have some ethics.

If UMN is an APT group, then it is reasonable to ban them.

they wanted to show / remind about a way which could allow apt to do some very bad stuff

They wanted to write a paper. APTs have been trying to put holes in the kernel for 20 years now… this is not news.

Surely the hot take should be that the kernel is at risk of a malicious actor introducing bugs that can be exploited, not "Oh, we already write bugs so it's not a big deal."

This seems like a rather lackadaisical take on the situation.

To add to that, the key takeaway is that they conveniently just shrug such risk off, because the alternative is more work they don't have capacity for.

I mean, it's not like dependency package injection have been proven to be a good way to hack back doors or anything. /S

P.s.- as a non contributor, I know I'm being a bit dickish. The truth is these researchers proved thier point in spades and no one wants to admit it. I

Twenty years ago, this incident would have been met with a "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should." A decade back, "play stupid games, win stupid prizes" would have won out. Now, I think The Kids would say "Fuck around and find out" (this is often accompanied by a stencil of an open-mouthed alligator).

No matter the form of the reaction, I am still left wondering at the proportions of disregard, hubris, naivete, and perhaps sheer lack of consideration of consequences that went into this whole affair. For the life of me I simply cannot imagine anyone patting me on the back and saying, "Good show on that paper, old boy! Smartly done!" Was there nobody in the whole group who had reservations? Were any expressed or were they simply hidden away? I am sincerely curious as to how it managed to get to this point.

I'll be the odd one out and say that I see nothing wrong with their study. There are much more skillful, much better resourced actors who can do what the UMN did much more discretely.

I mean, the UMN flaws were egregious and blatantly obvious. They should have been met with ridicule at first glance. If they aren't (and they weren't), there are problems that need to be addressed.

But there's a torch mob about this -- a very misled, and I would say foolish torch mob -- and as a result comments like mine will invariably be moderated down to invisible. I guess if we just brigade against some junior researchers it'll help defend the kernel from actually malicious actors...

If UMN’s ethics review(s) has approved this experiment in cooperation with Linus/Greg, there would not be anything to be outraged about.

The outrage, and the core ethical violation, centers around intentionally wasting the time of others for selfish benefit without appropriate review and consent.

> If UMN’s ethics board has approved this experiment in cooperation with Linus/Greg, there would not be anything to be outraged about.

I do not think that would help. This was done on public mailing list and deceptive behavior was also against third parties (other reviewers). I do not think Linus/Greg can give consent to that.

Within the scope of the project, Linus and Greg absolutely could deem this acceptable on a project basis. Individual contributors might then leave the project once this comes to light, but if the project owners say “We need you to submit an 8 hour video of paint drying with every commit”, that’s their right to do so, and if they say “We chose to allow researchers to waste hours of your collective project time for a experiment”, that’s their right to do as well. If they want to guide the project down seemingly-unproductive paths because they truly think it’s worth it, then they will.

The difference is one of these gives you the opportunity to consent or opt out of the wasting of your time, the other ones doesn't. You aren't describing ethically equivalent things.

With an experiment of this nature, it is not always possible to get universal consent-or-refusal, due to the nature of the experiment. If you're doing an experiment with footpaths and you want to close specific paths to see how people's behavior changes, you do need to seek permission from the owner of the footpaths, and you do need to perform some sort of ethics review to ensure you aren't creating severe mobility issues for those being experimented upon, but you would never be expected to seek permission from each person traveling those footpaths to waste up to a minute of their time by closing the footpath they intended to traverse. Whether or not that time waste is acceptable is ultimately the decision of the owner/operator of the footpaths, not of the individuals using it.

So, then, it is similar with a 'secret experiment upon unwitting people' and the Linux project. The owner/operators are Linus and Greg, and as the experiment cannot be pre-announced without tainting the outcomes, they are the ultimate "go or no-go" decision makers — just as the owner/operator of the footpaths would, too, have a right to refuse an experiment upon their participants. The individual Linux contributors who participate in the Linux project have no implicit authority whatsoever in any such consideration, and would not be offered opt-in or opt-out consent prior to it being performed. If the good of the project requires pentesting the processes that contributors operate, the project has every right to do so; it's for the good of the project, and contributors' time spent will have been net valuable even if the specific contributions are felt to have been "discarded" or if the contributors feel that their time was "wasted".

This lack of individual authority in many respects is not comfortable or appealing for open source contributors to consider, but it's critical for us to confront it and learn lessons from it. We do not perfect authority over how open source projects use our contributions, whether in time, money, or code. Some percentage of our contributions will always end up being discarded or wasted, and sometimes that will be upsetting to contributors. These are real aspects of project participation regardless of whether secret experiments are approved by the project owners/operators or not. I hope that this event helps us develop better empathy for large projects, such as Linux or other operating systems, when they make decisions that benefit the project rather than contributors.

With an experiment of this nature,

I think the thing I'm objecting to is that this is a valid or meaningful 'experiment'. Placing there, to me, is already inaccurate framing.

In a previous thread a user suggested the following:

Get consent from the project leaders and announce publicly their intentions and a time window of a few months. Then randomly submit the patches as originally outlined.

Although this would not prove as strong of a result, it is far more ethical and similarly effective. Companies use this kind of method all the time.

Wouldn't Linus/Greg be heavily criticized for such cooperation then? The nature of this experiment prohibits it from total consent with the process been experimented on.

They likely wouldn’t have cooperated with study, but advised that there is no point to it as there is no mechanism to catch the behavior they described.

It sort of like asking “What if we volunteered for the parks department and slipped a load of salt into the fertilizer?” - of course bad actors can find new ways to circumvent security.

"We found out that we have no process for confirming that we're applying the correct fertilizer to the soil in question, and accidentally salted the earth of a small patch of flowers during the test. While not ideal, the damage is small and contained and repairs are underway."

"The Parks Department responded by saying well duh, we could have told you that there was no such process, and then you would have avoided killing the flowers and wasting our time by making us check on everywhere else you were allowed to apply fertilizer".

No one’s discussing that, and I think that’s the most valuable question of all. Was this experiment so worthwhile that it ought to have been approved? Or was the experiment itself so irrelevant that ethical compliance or not, it shouldn’t have needed doing? Is random testing of gatekeepers an appropriate process in Linux development?

Actually I think this is a very good point you're raising. Maybe the kernel community has a whole should consider a way of checking their processes. Now randomly submitting buggy patches is probably not the right way, but there very well might be some interesting research (on the processes) that could be done. So maybe a document that laid out what would be acceptable and what not could be helpful.

There is no such thing as UMN ethics board, although they do have an ethics office: https://integrity.umn.edu/ethics. I don't think they get individually involved in specific studies unless there's been some sort of compliance violation.

It's also questionable whether the IRB should have considered this human subjects research and not given them an exemption. It's also questionable whether, if the IRB had done that, the IRB would have stopped the study or asked for revisions to the study design (they would if they were paying close enough attention).

Professors at universities are typically given large amounts of freedom to conduct studies without heavy prior approval, it's a tradeoff.

And it's a trade-off that the Linux maintainers have now justifiably called them to task on for making the trade-off in a way that pushed the cost onto external parties.

As the top level stated, "fuck around and find out."

Okay, “UMN’s ethics review(s)” encompasses whatever the exact ethical review process(es) are. Updated.

ethics is mostly self-regulated; when you apply for grants, the University ensures you're not proposing to do anything illegal (risk protection for the U), but subsequently doesn't actively monitor most researchers to ensure they are being ethical. Same for publications. In those cases, the response is entirely reactive, doing investigations and actions after the problem hits the press.

> If UMN’s ethics board has approved this experiment in cooperation with Linus/Greg

No, informed consent must be with all participants and maintainers reviewing the patches. Why does Linus/Greg get to decide that for others?

That is not as cut and dried a decision as you frame it to be.

California emissions testing for vehicles includes licensed smog test stations and a process where undercover inspectors bring cars that are in violation to those stations. If the smog test station is incompetent, they will be cited and perhaps stripped of their operating license.

If another state decided that they’d like to start performing random tests upon their network of smog test stations, without any retaliation to those stations, then it would not be a violation of ethics for that state to send undercover cars through the stations.

It would be unethical to punish those who fail undercover tests, unless the state had announced that random undercover testing was beginning and that punishments would be applied for failures.

The researchers were not attempting to modify the behavior of the participants, nor did they seem to be interested in naming and shaming specific maintainers, so it’s not as simple as “anyone who comes into contact with the experiment must be fully informed”.

A professor is not a government. Also, all governments will use uncover officers without warning first.

The analogy is from California to Linus/Greg, not UMN.

California controls the licenses for smog test stations. I would imagine there’s a clause in the contract that says “California, at any time, may do random undercover inspections of the smog testing facility to ensure compliance” which the owner of the licensed smog station would be aware of.

Do you see how that differs from an academic randomly experimenting on an open source project with no notice or warning?

Retail store owners/managers contract out “mystery shoppers” to test compliance with retail store policy and procedure. This example is also nothing like the UMN experimenting on Linux, since there’s a contract and both parties are aware.

A similar example to the UMN/Linux situation would be an academic doctor deciding to randomly test blood donor screening by sending in HIV positive people to lie about their status in order to donate tainted blood and only telling the Red Cross or whoever after the blood has been donated.

I guess that depends on whether you consider this a sociology experiment or white hat work.

I'm not sure that I agree that sociology experiments have 'informed consent' the way you appear to be thinking of it. Yes, you know you're in an experiment, but if you know what the experiment actually is, then your reactions are not authentic and you skew the results (which always makes me wonder about clever people in experiments).

In white hat stories, it's not always the case that everyone knows ahead of time, but 'enough' people know. Those who do know bear part of the responsibility of ensuring that things don't 'go too far', and they give organizational consent but not personal consent. Although I confess that OSS might be a little fuzzy here because I didn't sign anything when I started. You can't tapdance around informing me by pointing to some employment agreement.

You are free to disagree. Obviously, not every scenario can be navigated using an arbitrary policy for conduct, which was what clearly happened here. 'Informed consent' in the context of cybersecurity research is described in the Menlo Report [1].

And fyi, not all white hat stories are clean in their approaches, that in itself remains a controversial topic for another discussion. Furthermore, employees in an organization are under a different set of contractual obligations, full of caveats, to their employers. In some ways, they've already "consented" to specific bare minimums(white-hat can be framed as security awareness training required in your job role).

Open source contributors and reviewers are individual third party actors. No one has established any tolerance limits. So "enough" people doesn't really apply here because no one was made the arbiter source to decide that.

[1] https://www.dhs.gov/sites/default/files/publications/CSD-Men...

With senior endorsement it would be easy to recruit a pool of participants.

Yes, opt-in informed consent from maintainers and reviewers of the patches.

Somehow I feel that wasting some developer time in a situation where informing all the parties involved would have probably undermined the research itself, is a lot less of a ethical breach than full blown coerced human experimentation with permanent effects on those people's lives, which this research is being compared to. The outrage on HN about this experiment has been mind-boggling to me, how sacred people hold keeping the Linux kernel and its maintainers' time pristine. And ultimately it seems that the research was useful, given the blast radius it produced.

Time wasted is a permanent effect that cannot be recovered, so your argument falls apart.

What a rhetorical power move it is to preemptively decry "torch mobs" for having your comment disapproved of. You might also consider the possibility that you'll get downvoted for suggesting that "ridicule" is an appropriate response in a code review.

Maybe you haven't been paying attention, but the "torch mobs" have been pretty active as this situation has unfolded. There is nothing "preemptive" about it. The zeitgeist is pretty obvious.

As to the "ridicule", putting aside the out of place attempt to moral high ground about a rhetorical turn of phrase, yes their commits were so egregiously flawed that ridicule was the only response.

When a state level attacker carries out a successful attack via the kernel, then the developer community will hide behind shocked_pikachu.jpeg and call for more social engineering and red team training for the Linux foundation. Until then, people are happy being complacent and any attempt to change the status quo will be met with hostility.

Your comment will be downmodded because you mentioned it in advance and you haven’t actually stated why you think it was fine to abuse the open source maintainers other than “someone else can do it”.

“I beat my kids so some weirdo on the street doesn’t!”

Their particular problem in this case is that they are researchers at a reputable university. They are not supposed to be caught doing this, ever. Poorly supervised students coupled to disinterested faculty advisors is the recipe for this sort of non-sense.

Actually the supervisor was directly involved in this. I think it's much more the high pressure publish or perish culture, possibly coupled with the pressures of tenure-track hiring (I'm not entirely sure if the supervisor was already tenured).

> I'll be the odd one out and say that I see nothing wrong with their study. There are much more skillful, much better resourced actors who can do what the UMN did much more discretely.

Puting these patches under false pretense is deceptive behavior to other people, that is problematic regardless of whether the intent is malicious or just doing research.

I agree strongly. People demanding this be pursued in criminal court are seriously getting bent out of shape. "We can mob these people because they're super in the wrong and also utterly helpless to defend themselves against my righteous fury," is ridiculous.

They made an ethical blunder, but this wasn't Tuskegee 2.0.

Seems more ethical and positive experiment to have the students to work with historical data, you can find a metric on how easy it is to slip a bug into the kernel, maybe they could identify problematic trends like time of day/year when bugs can slip in, or time before a release.

Do we really need someone to prove that a malicious backdoor can be added? since real bugs happen then it is clear that the system is not perfect,

Imagine this would be allowed, then all contributions would need to be checked not for the regular kind of problems but for all those stealthy tricks, so instead of working on the kernel you would need to attempt to find on how each commit is truing to trick you , or maybe this is fine on it's own but is part of a bigger plan.

> and as a result comments like mine will invariably be moderated down to invisible.

Please don't downvote-bait or superciliously posture like that. It degrades discussion noticeably and breaks the site guidelines: https://news.ycombinator.com/newsguidelines.html. Note the second-last one. Also this one: "Please don't sneer, including at the rest of the community." Also this one: "Don't be snarky."

Okay, but he gets a comment from you and avoids a faded out comment. If his comment was simply faded out, you would not have replied. Frankly, you need to recognize that there is a mob mentality on this topic and that legitimate comments are getting downvoted.

The way to respond to a mob mentality is to respectfully supply correct information and patiently make correct arguments. That may not work, mobs being what they are, but the solution is not to lash out in frustration, call names and fulminate. That's worse in every respect: it inflames the mob, damages the commons, and gives readers even more reason to reject whatever truth you're advocating (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...).

Discrediting your minority/contrarian view while at the same time damaging the community we all depend on is self-defeating behavior. The only reason we do it is because it's extremely frustrating to feel outnumbered by people who hold a wrong view (or one we feel is wrong). We all need to find ways to process that frustration in ourselves, before we can't stand it anymore and get propelled into the comments to seek relief. The relief of venting is short-lived and soon comes back worse, in the way that addicts need a higher dose the next time.

I don't mean to pick on you or mumblemumble personally. We're all addicts in this sense, and it's in all our interests to find a better way. This experience of frustration is extremely common, as we all know—the internet being, to a first approximation, wrong about everything.

Thanks for the reply. I respect what you are trying to do with shaping the conversation.

Yes, you are right about the frustration and you are right about the addicting qualities. I did comment in frustration.

I would say, however, it is additionally frustrating when the overall tone of the mob comes across as one of invective, and yet an invective comment that is mob-dissenting gets the comment from the moderator.

It is not just about stating correct facts on this topic. There is a value judgment and moral judgment being made here. Goodness knows I don't feel comfortable commenting counter to the collective opinion here.

Again, I agree I commented in frustration and likely unproductively and I appreciate the intent to moderate good discussion.

I'm not sure which is the greater chilling effect, the way downvoting works out in practice on this site, or having the site moderator dismiss you as "sneer"ing and being "snarky" if you openly acknowledge the downvote's chilling effect.

Downvotes on HN are capped at -4. Go to Reddit and notice it's unbounded.

The comment seemed fairly reasonable until that last bit, which was unnecessary. I felt the moderation to be appropriate in that context.

Your GP comment is an example both of what we're trying for on HN and what we're trying to avoid. The first two paragraphs are fine, on topic, and make a good argument. The third paragraph goes into snark and resentment, and ends up in reductio ad meta. Your post would be strictly better with just the first two paragraphs. Is that so hard to see? As for chilling effects, I wish we could chill the latter kind of stuff more effectively, or better yet, freeze it out—it would make this site remarkably better.

Maybe the most common quality-degrading thing people do in HN comments is to resentfully represent oneself (or one's view) as the unfairly excluded underdog, the noble freethinker surrounded by a deranged mob, striving heroically to hold up the truth for a brief moment before the rabble crushes them. This simultaneously supercilious and victimish pose is something people do on all sides of every topic. I'd like this community to get a little more conscious about how badly it degrades the threads. That's the intention behind the guideline, "Please don't sneer, including at the rest of the community. Perhaps we can find a better wording that will make this clearer.

I don't mean to pick on you personally! It's extremely common, as I said, and the purpose of these moderation replies is not to scold (and certainly not to shame) individual commenters, but to try to shift the culture another notch in the direction of interesting discussion, which is what we're all here for.

I don't feel picked on. However, I do think that the way that downvoting works in online communities deserves some examination. And, given the basic structure of how HN works, community members don't really have a clear way to discuss it except by complaining about it in comments like these. Which isn't the best way. But still.

"Freezing it out", as you say, has the effect of shutting that conversation down completely, which I think is potentially harmful to the long-term quality of the discourse, and in a way that is rather more insidious than the rather more banal quality problem that you're trying to guard against.

In particular, the ever-present threat of getting voted down to -5 for presenting an idea that goes against the popular opinion presents a strong disincentive to share opinions, particularly for less thick-skinned individuals. And it creates a constant low-grade anxiety for some contributors. Pre-emptively complaining about the downvote is one symptom of this effect, but it's not the only one. Others, less visible, symptoms are that people just don't share their opinions at all, or don't share them as thoroughly or eloquently, when they're worried that doing so might result in the electronic equivalent of a smackdown.

And the fact that this phenomenon affects certain people more than others does put a spin on the conversations that take place on Hacker News. Not necessarily one that has the effect of elevating the quality of discourse over the long run.

Well, that's a pretty decent reply. In any case, we can't freeze it out, so if you're right about how bad that would be, at least we're escaping that particular fate.

I wasn't meaning to say that your efforts at freezing out conversation about the downvote are having that effect. I'm saying that's the effect of the (current) downvoting mechanic itself. What you're trying to freeze out is people expressing, however indirectly, a legitimate concern about the social environment being created by the current mechanics of the site.

In other words, I think you're being a bit too quick to the trigger to dismiss these sorts of comments as just being boring conversation. My impression is that they're actually a rather banal tip to a much more consequential iceberg. You can't see the rest of it because it concerns things that are mostly happening out of view, out in meatspace, and typically only manifest themselves indirectly in what's happening on Hacker News. Especially if you're trying to "freeze out" the more direct manifestations.

You completely ignore the issue of consent.

The UMN has placed itself on the same level as those miscreants, because they screwed up in several different ways.

Finally, maturity is, in large part, knowing the difference between having a capability and exercising it. As an institution, the UMN has revealed itself to be immature. What they do about it now determines how they will be treated in future.

They acted just like actual malicious actors by not letting anyone know or asking for consent on their experiment.

Try robbing a bank and then claiming you were just testing their security and it was just for research, see how well that works out.

And it's not too rare, either. Tests of "supply chain attacks" have actually uploaded sample packages to package repos like NPM and PyPI, and the professional researchers collected bug bounties. Meanwhile the volunteer repo admins often take the blame and have to clean up all the fake packages too. https://arstechnica.com/information-technology/2021/02/suppl...

The difference is that the bug bounties are being collected from an endorsed bug bounty program.

Fake and malicious packages jam public collections regularly, and are not part of white hat research. It's a trash fire which seemingly only gets better with exploits forcing people to change.

The bug bounties are from companies who use the repos, not the repos themselves.

> Was there nobody in the whole group who had reservations?

I've seen very well-intentioned people do very stupid, seemingly callous, etc things that would make anyone who didn't know them question their quality as a human being.

My answer to these kinds of situations has been to remedy it and move on quickly. The more you dwell, the more possibilities and random connections pop in your head, and the easier it is to believe everybody is just a selfish, evil, etc person; which is far from the truth if you've chosen to live life a little.

The academic ivory tower is real. I have seen tenured professors with tenuous grips on the reality outside of academia. Something like this kernel affair seems pretty plausible to me

Wonder if anyone involved was on the tenure track. If so I assume they can kiss tenure goodbye.

It looks like the lead faculty is likely going up for tenure in a year or two.

>> Was there nobody in the whole group who had reservations?

Based on my experience (not at UMN), reservations expressed by juniors are dismissed and the seniors keep their reservations to themselves, lest they also be dismissed.

There are plenty of examples of the entire decision tree being tone deaf from the real world not just in academia. Often times, this turns out to be because the group involved is not very diverse so the group "experience" is not as wide. How many times has something with a double meaning been used in marketing where the world gasps and asks "was there not one person involved of ____ race/sex/age/etc?"

Linux is arguably one of the most important software projects on the planet right now.

It is vital in so many aspects of society now, Android, AWS/AZure, IOT, routers, etc etc.

It should be taken as a serious given that bad actors are working hard, with huge budgets to nefariously gain some advantage in the development of Linux.

They will have far better engineers, much larger budges, and have been working on it for many years.

I would imagine ever intelligence service on the planet would love to have obscure exploits embedded in the kernel.

I can easily imagine a scenario where a single exploit was introduced over many months one tiny bit at a time. Each patch a fully working fix for unrelated problem. Fully Legit. But when they are all combined something wonderful happens. (for the nefarious player).

This stunt was a few students who were not well funded nor were they uber kernel coders. Yet they had some success (depending on what you call success).

I imagine the NSA has a team on this, with some exceedingly well skilled kernel coders working on embedding things, and I am sure they have a second team to find possibly implants by foreign services and so on.

Had this been security researchers who managed to get changes into the WindowsNT kernel I think the reaction by the core Linux devs would have been different. (and yes I am 100% there are people spending just as much time doing this for Windows as for Linux, well maybe not).

This highlighted a vulnerability, which is frankly quite real and needs to be taken seriously and contemplated over time.

The guys were jerks, yes. What they highlighted is real and a lot more serious than what this little stunt did.

I think the article raised a good point:

"One final lesson that one might be tempted to take is that the kernel is running a terrible risk of malicious patches inserted by actors with rather more skill and resources than the UMN researchers have shown. That could be, but the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more. "

How big/useful a revelation is it that you can show it's easy to break into someone's house while they are sleeping if it's well known the front door won't even stay shut.

It's not that the front door won't stay shut, it's that different portals to the house seem to be locked or unlocked or just plain open sometimes at random intervals. There is benefit to an attacker to having a known ingress available on demand.

There's a difference between a bug, a potentially exploitable bug, and an exploited bug. There's also a big difference between what's known and what's not yet known. Just because kernel developers are busy inadvertently introducing bugs doesn't mean that those bugs are all equally useful as an exploit.

And that's before even considering that some bugs are easier to identify than others. A sophisticated adversary being able to get an exploitable bug into the kernel that they already have an exploit built for skips the discovery and exploit development phases, while also ensuring that the exploit delivers the type of access desired, rather than depending on luck.

This is definitely something we should be thinking about.

It is interesting that there isn’t more emphasis on requiring automated tests with Kernel changed. It’s clearly impossible to verify that every change is safe, yet test coverage isn’t part of patch acceptance criteria.

There’s likely more coverage on a typical website.

I broadly agree that tests should be part of the patch acceptance criteria for core kernel features. That's a no-brainer these days and with kunit it's not even that hard to write kernel unit tests.

I will say that there are a fair few test/fuzzing suites for the kernel (xfstests, selftests, kunit, the Intel 0day finder, syzcaller, etc). The last two I would argue are probably more likely to find exploits than unit and integration tests. There also has been a push in recent years to have better test frameworks for the kernel. (The reason I'd like more integration tests is because sometimes new kernel functionality is added without a strong enough specification of what it's behaviour should be -- writing tests tends to cause people to consider those corner cases.)

However one issue is that the vast majority of the code in the kernel is for drivers. It seems to me that it'd impractical to even attempt to mock hardware (since drivers also have to work around hardware bugs), so you'd only be able to do fairly rudimentary unit testing for the bulk of the code in the kernel. Modern websites don't have embedded drivers.

> the other three (1, 2, 3) contained real bugs. None of those three were accepted by maintainers, though the reasons for rejection were not always the bugs in question.

Wait, so none of the maintainers were actually fooled by these hypocrite commits? In 2/3 the maintainers explicitly caught the use-after-free bug on their own, and in the third they had some unrelated feedback. Maybe I mis-read their paper, but they made it sound like if they hadn't told the maintainers "wait, don't merge this, it's bad" they would have introduced vulnerabilities into the kernel. But that isn't what happened at all!

Again, maybe I mis-read the paper, but it seems like we can add dishonesty, if not outright fraud, to the list of problems with these researchers.

Possibly? It depends on whether you think every patch they submitted was part of the research.

> Thus, one of the first things that happened when this whole affair exploded was the posting by Greg Kroah-Hartman of a 190-part patch series reverting as many patches from UMN as he could find. Actually, it wasn't all of them; he mentioned a list of 68 others requiring manual review because they do not revert easily.

> Most of the suspect patches have turned out to be acceptable, if not great, and have been removed from the revert list; if your editor's count is correct, 42 patches are still set to be pulled out of the kernel.

> For those 42 patches, the reasoning behind the revert varies from one to the next. In some cases, the patches apply to old and presumably unused drivers and nobody can be bothered to properly review them. In others, the intended change was done poorly and will be reimplemented in a better way. And some of the patches contained serious errors; these definitely needed to be reverted (and should not have been accepted in the first place).

This is a reasonable and balanced analysis of the situation. In retrospect, it seems like the reversion of the 190 patches was an overreaction that ended up causing a lot of confusion: many people even on HN misinterpreted the comments on reversions to believe that bad patches were committed to the source tree or to stable.

But besides the lesson that one ought not to be deceptive with submitting patches, is also the lesson that the kernel is not as well reviewed as one may hope and with some effort, it's certainly possible to add an undetected vulnerability. I think that's probably one thing that led to the drama, is that the fundamental trust and work of the kernel was attacked, and the maintainers felt the need to fight back to protect their reputation.

I don't think the latter part is true, my impression is that the kernel people are very well aware of the limits of their review ability and don't pretend to be unfoolable.

There's a wide range of degrees between "unfoolable" and "can be done by a persistent student". I think the impression (at least my impression) used to be is that it was possible before but quite unlikely without state-level efforts, but now we understand a properly advised student can get most of their attempted vulnerabilities inserted.

The pure number of just regular bugs that aren't caught is already a good indicator that not much special effort is needed. (And "just a persistent student" isn't that little, given that the group also contributed regularly to the kernel, was studying its security, ... and thus quite familiar with the field, and the kind of people a nation state would employ for that)

The harder part is probably fooling all of the static analysis tools that get run on the kernel, Coverity, Coccinelle, Smatch, and so forth.

190 patches were not reverted. 190 patches were proposed to be reverted, and those reverts have been going through the normal kernel review process. In many cases, the patches were confirmed to be correct, and so the revert was dropped. In 42 cases, those commits were found to be inadequate in some way; in some cases, the commit didn't actually fix the problem, or introduced another problem, or I believe in one case, actually introduced a security problem(!). Call those last set of patches, "good faith hypocrite commits".

Remember, too, that many of these commmits were in random device drivers. Consider how often random Windows device drivers crash or cause random blue screens of death. Not all "SECURITY BUGS (OMG!)" are created equal. If it's in some obscure TV digitalization card in the media subsystem, it won't affect most systems. Core kernel subsystems tend to have much more careful review. As the ext4 maintainer, I'm a bit slow in accepting patches, because I want to be super careful. Very often, I'll apply the patch, and then looking at the changed code in the context of the entire source file before approving the commit. Just looking at the diff might not be enough to catch more subtle problems, especially dealing with error handling code paths.

The problem with device drivers is that in some cases, they are written by the hardware engineers that created the hardware, and then as soon as the hardware ships, the engineers are reassigned to other teams, and the device driver is effectively no longer maintained. One of the reasons why some maintainers are super picky about allowing device drivers to be admitted to the kernel is because the concern that driver author will be disappear after the patch is accepted, and that means the subsystem maintainer is now responsible for maintaining the driver. So if you want to sneak a SECURITY BUG (OMG!) into the kernel, targetting some obscure device driver is the going to be your simplest path. But that's really only useful if you are gunning for a IEEE S&P paper. The obscure device is not likely to be generally used, so it's not that useful.

(Unless, of course, you are a hacker working for Mossad, and you are targetting a super obscure device, like, say, a nuclear centrifuge in use by Iran.... in that case, that security vulnerability only works on a very small number of systems is a feature, not a bug. :-)

You mean sometimes you don't look at the change in the context of the whole file? That's terrifying.

I assume it depends on the nature of the diff? I do a lot of code review at $JOB, and sometimes the diff is so obvious that there's no need to look further.

OTOH if the code is something that I've haven't looked at in a while or don't understand that much, I'll read around a bit and see if there's a way the diff can be improved.

My take away from this affair is how we again and again overgeneralize. It never made any sense to blame UMN in general for an action taken by arguably only a single department, and even holding them culpable is a stretch (this is in response to some people in another thread saying no one from UMN should ever be able to contribute to the kernel ever again to teach them a lesson).

It's not really surprising a bunch of academic-types were too far removed from open source etiquette - that removal is pretty much the source of the drama (this entire thing would've been avoided if a few key people were informed ahead of time).

My other take away is that it seems social engineering still is the most powerful type. From this to the Twitter fiasco - it's worth trying to make your workflow resilient against social engineering indeed - by the authors own admission, the process leans a bit too much towards pre-established trust and credibility. Unfortunately that trust isn't immutable, nor is it everlasting so it's a spot that can be exploited.

If the university doesn't review research methodologies that directly impact others (I'm not talking about societal impact of the work down the line), then they should be considered bad-faith actors. This is the equivalent of punishing a university for not having an IRB for human experiments .

I assume individual members from UMN may still contribute without a UMN address. They just won't be given any special consideration (implicit or explicit) as belonging to a particular organization.

By that standard, basically no university meets your threshold. (in other places the IRB might have decided differently, but also that's not extremely likely) Researchers are just not monitored that closely usually.

They'd already complained to UMN about the research, and nothing was done about it. It wasn't just the IRB that allowed it to continue.

Is that the case? I hadn't seen anything conclusive that that actually had happened? (some people said the contacted the IRB, but presumably that was part of what triggered the IRB to look at it)

But looking into this and clearly documenting it is part of what UMN needs to do.

In the most recent email chain where they banned UMN, GKH said that they were going to have to complain to the university again. From what I understand, the IRB review was initiated by the researchers themselves after receiving backlash from the original paper.

What do you mean continued it. The research of submitting buggy patches had ended already (they even had a draft paper). The whole row started because one of the researchers submitted a patches from a (not very good apparently) in progress static analysis tool. The bad quality of the patch led to GKH accusing the submitter that they are continuing. As the article states this was not the case.

But researchers don't operate within a vacuum, research is a social effort. The faculty member and the graduate student who dreamt up this line of research have discussed it with others and they all thought it was a splendid idea.

>By that standard, basically no university meets your threshold.

The question then, is what to do about this much larger scale problem, not to simply assert the premise is wrong.

Agree or disagree with whether it should have been done but blaming UMN was a social tactic to embarass the University so that UMN would apply pressure to the researcher and deal with them.

> social tactic

This, but not derisively. Note that the university's IRB granted an exception for this behavior, and neither UMN nor the department responded with consideration for the concerns raised by the kernel team until after they banned the whole domain.

The social tactic could have been changed from "we will revert all recent patches originating from UMN" to "we are forced to review all recent patches originating from UMN, and to enforce stricter scrutiny of UMN patches going forward." Second is more honest and also applies social pressure.

The second option also doesn't result in any big negatives for UMN associated personnel because the kernel devs take on all the work of enforcing stricter scrutiny.

That sounds like a good first warning. But they persisted even after Greg KH complained to UMN and told them to stop. A more severe punishment for a second offense is needed, IMO.

> It never made any sense to blame UMN in general for an action taken by arguably only a single department

UMN is ultimately responsible for the actions of the people under their organization. This include oversight and dealing with the actions of those people when they have crossed lines.

Agreed, and I'm stunned this is even in question.

> It's not really surprising a bunch of academic-types were too far removed from open source etiquette

Umm, there's etiquette in academia too you know... even FOSS etiquette in academia.

And that fact highlights the mistakes made here.

A fellow researcher intentionally pushing bad data into a colleague's study as some kind of penetration test on the colleague's scientific methodology would be justifiably seen as betrayal, and a possibly bad faith betrayal at that since research grants are a finite resource.

The researchers in the story appear to have failed to extrapolate that sort of collegial courtesy to the open source community maintaining Linux.

The researchers in this story acted unethically - as academics. I'm saying it's not the culture difference.

HN meta point

> The old saying still holds true: one should not attribute to malice that which can be adequately explained by incompetence.

This is exactly the comment I left on the original HN thread, which was downvoted [0]. I can understand the kernel maintainers being overwhelmed by the situation and jumping to the worst case interpretation, but interesting to see HN commenters doing the same, too.

https://news.ycombinator.com/item?id=26890520

HN went really emotional about this particular matter

HN also often suffers the same fate as other social networking sites, where comments that don't align with masses get downvoted

If I dropped by a UMN researcher's office and asked for 30 minutes of their time for something they consider unimportant, they could reasonably reply, "no, I'm too busy with research". Likewise, a kernel developer should not be forced to unwittingly waste their time. The "malice" here is that the researchers may consider their time more valuable than others. Incompetence is a separate thing.

Lastly, kernel developers are naturally going to trust computer scientists at major universities. The researchers know this (subconsciously or not) and took advantage of it. Patches from smith@joeschmoe.com will automatically get more scrutiny.

But that is not what happened. In the bug submission experiment they used Gmail addresses not their UMN addresses. The whole thing came up when one of the students (I think he was a graduate student working in the research group) submitted patches from his over eager static analysis tool using his uni address. So if anything the work from the uni adress received more scrutiny than the other patches.

OK, agreed, I was wrong on my second point.

If the original headline had been "graduate student submits auto-generated patches wasting several hours of kernel developer time," I sincerely doubt there would have been any outrage. Certainly no one would be calling it proportionate to ban the many tens of thousands of people at their university and to revert every patch they had ever submitted.

Unfortunately for the graduate student, their lab had previously written a paper about sending buggy patches. One thing leads to another and we have "the UMN Affair"

I read your comment and felt the same way. I also thought you didn't deserve the down votes (I think I even gave you an upvote to counteract, even though I hardly ever vote).

I found the reaction to this surprising.

When Security Researcher tell a company about a bug they've found, and the company reacts badly, this community is usually strongly in favor of the Security Researcher.

The overworked corporate sysadmins don't get a lot of empathy. The assumption seems to be that that their software shouldn't have been vulnerable in the first place.

Now here's a security researcher researching smuggling bugs into the Linux kernel. It probably should be secure, and probably should face scrutiny. People have tried snuggle bugs into it before.[0]

So why is the opinion so strongly against the Security Researcher here?

What's the big difference in principal?

[0] https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-...

My opinion: security researchers attack an organization’s products, like their code or website or services. UMN attacked the organization’s people to test their defenses.

Lots of companies run bug bounty programs and thank you for finding vulnerabilities in their product. Humans don’t scale so well, though, and if you pester the hell out of a company’s office manager trying to social engineer them, that company is going to be super freaking annoyed at you.

If UMN had analyzed the Linux code to find problems, then patched them, the kernel team would be happy. They didn’t. They spammed the human maintainers with a flood of patches and lied about why they were sending them. They conducted an impromptu and unanticipated phishing test, and you just don’t do that.

One big difference is explained in the article. The fact that code going into the kernel is not as secure as we might hope is already known to the open source community. Maintainers are overworked and none would be surprised if you told them that it would be possible to smuggle in backdoors. This is not a "bug", but an issue with time and resources, and because the researchers attempted to add bugs to demonstrate it just makes it worse.

On the other hand, security researchers are finding vulnerabilities that weren't previously known. They've discovered specific exploitable bugs, rather than introducing new ones. Following disclosure, the company can patch the vulnerabilities and users will be safer. Which makes that a laudable thing to do.

Apart from the understandable annoyance (anger) of being experimented on and the scandal that this somehow got approved by the UMN ethics board I did find the reaction to this somewhat interesting in that the kernel community was willing to immediately ban every one from UMN (a university of significant size) and investigate/revert all patches originating from UMN. In contrast I don't believe the reaction was anywhere near that strong when it came out that the NSA likely subverted a crypto standardisation process. Should the kernel community have reacted at least equally as strong (if they did and I'm just not aware of it please educate me).

From the UMN response signed by the Computer Science & Engineering department head and associate department head:

The study was focused on understanding a system by identifying mechanisms through which security issues could be introduced in Linux software. Therefore, purely as a technical matter, this study did not qualify as “Human Subjects Research” and received no further scrutiny or oversight from the IRB. Importantly, even if one believed the study did involve human research subjects (perhaps due to the interactions and the incidental collection of email addresses), the study would clearly be exempt from IRB oversight pursuant to 45 CFR 46.104(D). In other words, the UMN IRB acted properly in this case.

Full response:

https://drive.google.com/file/d/1z3Nm2bfR4tH1nOGBpuOmLyoJVEi...

Ok I guess this shows my ignorance on what constitutes human research (although I'm outside the US and definitions might be different here). I have to say this is a good response letter from the department.

> In contrast I don't believe the reaction was anywhere near that strong when it came out that the NSA likely subverted a crypto standardisation process

It was pretty strong. There were many calls to remove the chair of the IETF CFRG group because of his association with the NSA: https://news.ycombinator.com/item?id=6942145

I really think this whole thing would make for entertaining content on one of the YouTube drama channels. Overall, I thought the kernel team was right to be upset about being experimented on without consent, but the exchanges on both sides had some notable incidents of immaturity. I didn't think the attacks against the static analysis guy were totally justified. They were calling him an idiot for putting in an unnecessary null check. To be clear, he then also overreacted, and that really made me think that it only takes one side to start de-escalating things.

The most disappointing response IMO was from the University itself. I didn't like how they deflected off the issue of why there was no IRB questioning of this. Just because human experimentation is narrowly defined federally doesn't mean you can't have higher standards.

... And I'd still like some update on the UMN IRB, which exempted this research.

Graduate students will make mistakes, and as much as this was stupid, reckless, and unethical, graduate school is a time to learn.

Professors will make mistakes. That's less excusable.

IRBs are set up exactly to prevent stuff like this. My experience is they don't work, and UNM's clearly doesn't.

IRBs are set up to prevent costly lawsuits against the university, although they were originally intended to avoid human experimentation like the nazis (and many eugenecists and other doctors in the US) did.

There are informal mechanisms as well. Someone will say to a hotheaded or greedy faculty member "look, you can't boot M off this patent, three years ago that other faculty member booted N off a few patents, there were issues, and then we had to pay tens of thousands for all the amended filings!"

This is false.

IRBs are required under federal law, which did result from ethics violations, both by the Nazis, but just as much by US-based experiments, like the Stanford prison study, the Tuskegee Syphilis Study, Yale's Milgram experiment, US-based human radiation experiments, and so on. At some point, we decided we should have ethical research. That's designed to solve a broad set of problems.

Most of this isn't about law suits but about federal research funding. There's little private right of action, but if you don't have research reviewed by an IRB, you can't get federal research grants. OMB requires an IRB.

That said, universities are finding loopholes. A major one is for profs to do research on "private" time as "consulting." Lots of unethical research being done and published that way. Professors don't really have a clean split between work/life or work 40-hour weeks, so while perhaps this started out reasonable ("I'm consulting to Google"), right now, it's just a way to bypass IRBs.

As a footnote: What's not widely recognized in the US yet were the close ties between Nazi research and US research, pre-war. A lot of the eugenics stuff was developed by the American scientific establishment.

I don't know why you're saying what I said is false. What you're describing is the law that makes them obligatory. But that doesn't define the role they play today, which is entirely more subtle than that. They focus on risk reduction for the university, not to ensure ethics. How do I know? Because I've worked with IRBs for years and know exactly what and how they do.

I made it quite clear the eugenics was primarily American.

interesting that they admit that going forward, they don't really have the resources to fully vet all submitted patches to the degree necessary to prevent something like this from happening again. seems like, if nothing else, this has proven the Linux kernel as pretty vulnerable to similar, more malicious future attacks. there's no real easy solution to this problem

That's not really news though, and IMHO one of the major points of criticism against the researchers: If what they did would have shown anything new or unsuspected it'd have been one thing, but they didn't, and could have shown the same with less impact.

The research was a little more compelling than that, since they did use an automated tool to find the partial vulns that they could sneakily upgrade to complete vulns. That is a little more interesting than introducing an entire complete vuln in a patch and hoping nobody notices.

Still very unsurprising, but a little more interesting than how the work has been presented in media.

I do also still believe that Oakland was incredibly foolish for accepting this work and that the PC has almost as much egg on their face as the researchers.

What an absurd statement. Malice implies intent ie: the goal was to do harm. There was never any malice - not in the hypocrite commits and certainly not in the static analysis findings.

Yes, malice requires intent, but intent can be interpreted differently too. If I shoot a gun repeatedly in the air for a celebration, I'm not intending to kill someone, but I am intending on acting in a way that has reckless disregard for human life. Malice is an appropriate interpretation of that kind of action, IMO.

What? No, it isn't appropriate for that kind of action. That would be negligence. Malice is defined as deliberate harm.

When you have a reasonable assurance that your actions will cause harm, and you do it anyway, that is virtually indistinguishable from intent to cause harm.

No, sorry, that's not how words work. Greg very clearly was implying malice, and intent, which there was none of. I don't care how bad you think the research was, you're welcome to call it negligent, but it was not malicious and it's totally absurd to try to change the definition of the word post-hoc.

Yes, it actually is how words work. They're imprecise, layered with meaning. Deliberately introducing bugs into the most widely deployed OS in the world has severe real world consequences. If you drive 100mph down a residential road, it is no longer an accident when you kill someone.

Yeah, it's literally manslaughter, because it is NEGLIGENT and not MALICIOUS.

And, beyond that, NO ONE introduced bugs into the kernel, and Aditya never even participated in the research that you're attempting to reference.

Greg repeatedly accuses Aditya of intentionally and maliciously introducing bugs. He is explicit about this. Trying to change the definition of malicious is ridiculous when the context is so blatant.

Wrong again. It is murder, not manslaughter. Manslaughter would be killing someone cause you got a text message and decided to take your eyes off the road to read it. If you know your actions are likely to hurt or kill someone, and you perform those actions regardless, it literally meets the definition of malice with respect to murder charges. More specifically, that type of intent is formally defined as implied malice, which is one of two types of malice aforethought, which is the legal standard for the crime of murder vs manslaughter. It is you trying to redefine the word, not me...you're trying to narrow the definition of the word to exclude valid usages of it.

https://www.sevenslegal.com/criminal-attorney/difference-mur...

This team intentionally sought to introduce bugs into the Linux kernel, just to see if they could. Entire companies, governments, organizations, microeconomies, and lives are literally dependent on the integrity of that kernel. That is malicious.

> If you know your actions are likely to hurt or kill someone

They never thought this. For good reason - they didn't harm anyone.

> This team intentionally sought to introduce bugs into the Linux kernel

Do your own research, they never merged those patches, they alerted the kernel developers before anything landed.

> Entiree companies, governments, organizations, microeconomies, and lives are literally dependent on the integrity of that kernel.

Sounds like understanding that it's trivial to convince kernel devs to merge in backdoors would be some pretty useful research.

Anyways, I'm done with this conversation.

Black hat hacking is also pretty useful, because it demonstrates the need to close security holes. But it's also wrong because it takes advantage of real people who have not consented to it. Are you in favor of black hatters too?

The fact that they tried to do this, even if they didn't follow through with merging, and even if they eventually came clean about it, is bad. Malicious bad. The lack of informed consent is absolutely critical in calling it malicious. If you want to do that, get GKH's permission first and recruit him to participate in the research. Don't try to slip it under his nose. It's one thing to A/B test your conversion rates, and another thing altogether to A/B test airplane wing flaps.

Maybe (as in it is possible, but not an incontrovertible fact) Aditya's role was not malicious, but he was surrounded by people that actually were malicious, and it is an entirely reasonable assumption to make, given the circumstances. If Aditya really does not want his name sullied by this, he should be making extreme efforts to disassociate himself from his advisor. By not doing so, his begging to be treated differently from his peers sounds like the pleas of a getaway driver hoping to not get charged for the bank robbery that his passengers committed.

> By not doing so, his begging to be treated differently from his peers sounds like the pleas of a getaway driver hoping to not get charged for the bank robbery that his passengers committed.

My gosh I hope you're never in charge of administering justice anywhere because this is just not how justice works in almost any liberal democracy. Say what you will about Prof. Kangjie Liu and his group and the patches themselves, but guilt through mere association is a dark thing to believe in. Takes like this are why so many people feel that, even though the UMN researchers were in the wrong, that the reaction has become mob-like.

All of the following are true about Aditya:

- Used a static analyzer to programmatically create and submit low quality patches to the kernel

- When a maintainer pointed out that his patches had bugs, he ignored them.

- The static analyzer that was used was also used by his advisor who used it to identify sections of code that could be used surreptitiously for "hypocrite" commits with intentional bugs.

- When caught submitting low quality patches with actual bugs, and it was pointed out that he directly works under the professor who was leading the hypocrite commits project, he didn't distance himself from the professor. All he could point out was that his name wasn't on the paper.

- He hasn't stopped associating himself with his professor, nor has he denounced the ethical basis for that research. All he can say is that he had good intentions.

When you take all of the above into account, it sounds like some major crocodile tear bullshit. Maybe it is all true and he wasn't trying to pull a fast one, but they're not trying to punish him, they're just trying to figure out if they can trust him. And there is no way in hell I would trust him with kernels that I use on a daily basis.

So, basically, Greg is kind of a jerk too. I mean I respect the dude for all the work he does but man his back and forth with an honest person and jump to ascribe malice looks pretty bad in this light. An apology might be in order.

What? Greg's open-source work was maliciously attacked by the exact same actor who then submits incompetent patch requests. I think he responded in a totally appropriate manner.

He does not owe these people anything - and certainly not kindness after their track record.

It wasn't the same person and it wasn't an attack. Read the LWN article.

By "actor" I was referring to the institutionally untrustworthy UMN, but since you seem interested in splitting hairs, you should probably realize in doing so that Aditya Pakki === Aditya Pakki.

Notice that Aditya is one of the signers of the apology letter: https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2YJL...

And that several of the identified vulnerabilities were tied to Aditya: https://lwn.net/ml/linux-kernel/YH+zwQgBBGUJdiVK@unreal/

Aditya's commits--though some were low-quality and/or buggy, including the one you linked--were not part of the intentionally deceptive "hypocrite commits" project.

UMN has many tens of thousands of students and faculty, on a similar scale to say Mountain View. It isn't "splitting hairs" to distinguish between the actual people involved in the untrustworthy behavior and everyone else.

I don't think Greg was totally off base, though I do think he could have been more restrained. Aditya was essentially spamming the reviewers with bad patches and doing zero due diligence, including, significantly, not responding to anyone pointing out flaws in the commits[0]; he did get the benefit of the doubt at first and had the opportunity to clear things up. Ultimately though he was collateral damage of his advisor's involvement with the previous study. One of the risks of deception studies, especially if performed unethically or irresponsibly, is that loss of trust.

Edit: While I don't think that suspicions or distrust were unreasonable, Leon's declaration that the commits were a direct continuation of the "hypocrite" research did escalate things unnecessarily[1]. I'm disappointed, though not surprised, by how many people--both commenters and tech news outlets--ran with that as the story at face value.

[0] https://lore.kernel.org/lkml/20210407155031.GA1014852@redhat... https://lore.kernel.org/lkml/bd3c84bc-6ae0-63e9-61f2-5cf64a9... https://lore.kernel.org/lkml/20210407153458.GA28924@fieldses...

[1] https://lore.kernel.org/lkml/YH+zwQgBBGUJdiVK@unreal/

Not sure if you're aware of how many students commit to the Kernel in exactly the same way Aditya did, but it's a shitload. Other maintainers have pointed this out, the response is guidance, not insults and slander.

> The old saying still holds true: one should not attribute to malice that which can be adequately explained by incompetence.

To the contrary, my takeaway from these events is a further erosion of the credibility of Hanlon's razor.

the razor holds IMO. because this isn't adequately explained by incompetence alone. the crafty/sneaky approach has some hints of malice.

That is actually totally fair. But I will offer a quibble: having to focus on the "adequately" part makes the razor less interesting.

But... it's there. Without the "adequately" its not Hanlon's razor, its random other razor that is probably less accurate.

People jump to Hanlon's razor way too quickly. The mere knowledge that people are likely to brush off things as incompetence instead of malice is a potential tool in the hands of the malicious.

Yes, all things being equal, it's better to err on the side of assuming someone didn't have malicious intent, but some people like to use it like a blunt instrument and the fact they do is dangerous in such a complex world.

Additionally, it's incredibly biased in its application simply because only a good-natured person would be inclined to brush off malicious action as incompetence. Malicious actors would be unlikely to do the same.

The situation has echoes of the scholars who a few years back submitted fake papers to journals, some of which passed peer review and were published. That was an attempt to backdoor the scientific method, really.

I don't condone guerrilla penetration testing whether its on the Linux kernel or a science journal, and I am sure that the ethical implications will be subject to much outrage and debate for some time to come, but when it occurs and is successful it is concerning because if a small team of scholars can do it, so can anyone else.

The inner workings of the Linux kernel maintenance has been kind of a black box for me for years, I just naively trust it works and my next update won't compromise my system, so it's concerning that this happened and will be following to see how this plays out.

I am not terribly surprised to learn that code review processes for the kernel are not as stringent as they should be. However, I do wonder whether the kernel's defect rate is significantly different from that of NT or XNU, and whether the situation could be significantly improved. I thought there was large institutional investment in Linux kernel development, but if the existing developers are horribly overworked and stand no chance of properly reviewing every patch, even from existing contributors, clearly the project needs more resources.

I'm glad that this situation has prompted reflection on these issues for kernel developers though. It seems like the best possible outcome.

What I want to know is whether the researchers had ever privately asked anyone in the chain of the kernel whether they would be willing to participate as a filter.

Bad example for obvious reasons, but if Linus was given the usernames that would be submitting bad patches and forewarning of which ones were valid and which ones weren't, it could have been done such that the experiment was valid and the commits were not included in the final tree.

I think it is a rather mild restriction to the experiment that a single person must be able to find an excuse to recuse themselves - as simple as "I don't have time to look at this, can someone else" would have worked.

> 42 [UMN] patches [out of the 190 listed by Greg Kroah-Hartman] are still set to be pulled out of the kernel... some of the patches contained serious errors; these definitely needed to be reverted (and should not have been accepted in the first place).... all of those [42] patches were accepted by subsystem maintainers throughout the kernel, which is not a great result. Perhaps that is a more interesting outcome than the one that the original "hypocrite commit" researchers were looking for. They failed in their effort to deliberately insert bugs, but were able to inadvertently add dozens of them.

> Of the remaining four, one of them was an attempt to insert a bug that was, itself, buggy, so the patch was actually valid

Absolutely legendary

That could be, but the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more.

That's the trouble with the one giant kernel architecture. Too much trusted code.

The QNX microkernel barely changed from year to year, and the number of kernel bugs approached zero. It's only about 65K bytes of code. Yet it could do most of what Linux does.

I think the problem is that the drivers are "inside" the kernel. Many of the dubious commits are there:

I think that's an evenhanded writeup of the situation, but I also think the author should have mentioned in the article that he is himself a member of the technical advisory board whose actions he's reporting on (if https://www.linuxfoundation.org/en/about/technical-advisory-... is up to date).

Some of the past related threads:

“They introduce kernel bugs on purpose” - https://news.ycombinator.com/item?id=26887670 (1954 comments)

UMN CS&E Statement on Linux Kernel Research - https://news.ycombinator.com/item?id=26895510 (320 comments)

Open letter from researchers involved in the “hypocrite commit” debacle - https://news.ycombinator.com/item?id=26929470 (374 comments)

Linux Foundation’s demands to the University of Minnesota - https://news.ycombinator.com/item?id=26955414 (168 comments)

“It’s easier to ask for forgiveness than for permission”, huh?

The older you are, the more you understand the importance of knowing this.

> the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more.

As an "average" dev I think the conclusion is totally unfair. Comparing a non intentional bug with intentional one(aka malware). I think Principle should matter and these people they violated the rules. And they should be morally shamed and legally sued. I certainly don't want to be mixed with them. Whatever people think of the quality of my code.

I understand that's a lot of work and just from a code quality prospective that's the same. But for the community of millions open source projects that's a terrible message to send.

> But if we cannot institutionalize a more careful process, we will continue to see a lot of bugs and it will not really matter whether they were inserted intentionally or not.

I've always known this to be the case with many FOSS projects. (Remember the Heartbleed bug?) I'm a little surprised it's an issue for something this critical that's used by all of the world's largest technology companies, including all of FAANG.

> Consider, for example, the 5.12 development cycle (a relatively small one), which added over 500,000 lines of code to the kernel over a period of ten weeks. The resources required to carefully review 500,000 lines of code would be immense, so many of those lines, unfortunately, received little more than a cursory looking-over before being merged.

I am more than a little astounded that new functionality is being added to the kernel THAT fast.

The thing that troubles me is how hundreds of good-faith patches came under suspicion.

We can say that the researchers are entirely responsible for that as well -- for creating that need for suspicion. But I do wonder if we were too quick to also fall into a pattern of outrage and absolute rejection.

This story went viral partly because it seemed much worse -- "And they're still submitting malicious patches to this day!" -- than it actually was.

I dunno, I think this is one case where outrage and rejection weren't too quick in coming.

Let's say you're a software architect (dunno if you are or not). You hire four new software devs, two of them from Colorado State University, and you put the two from CSU on the same team. After a year, you find out one of them has been secretly working for CSU's cyber security research department and poisoning your product with patches that do nothing or subtly introduce bugs on purpose purely so their professor can write a research paper about your company's process. Naturally, you fire the developer and that leaves a bad taste in your mouth and CSU promises not to interfere again. Then you get suspicious and start checking the work of the other CSU dev more closely and find out they're submitting bad patches too! They claim that these bad patches were submitted because their experimental static code analyzer didn't find any issues with them.

What conclusion should you reach?

You should conclude "I don't know whether or not these patches were submitted in good faith."

People sometimes submit bad patches. Not all of them are malicious.

I don't think we've fully addressed or explored the scenario where a young, bright-eyed aspiring student coder does in fact make an innocent mistake. And then is accused of deliberate malicious sabotage. And large chunks of the internet also start condemning them for deliberate and malicious sabotage.

What does that say about our community?

It's also important to understand the situation you are in - if you are the second CSU dev you got some extra due diligence to do. This is the real world, it's not fair.

> a buggy patch originating from an experimental static-analysis tool run by another developer at UMN. That led developers in the kernel community to suspect that the effort to submit intentionally malicious patches was still ongoing. Since then, it has become apparent that this is not the case, but by the time the full story became clear, the discussion was already running at full speed.

So they found a convenient scapegoat.

I am not buying it.

> The corollary — also something we already knew — is that code going into the kernel is often not as well reviewed as we like to think.

This may be true but not really a corollary of what happened. In fact, it seems there aren't the resources to determine how many of the patches are actually bad and should really be reverted.

reminds me of another potentially critical mistake, https://mncomputinghistory.com/gopher-protocol/

'According to Alberti, licensing “socially killed gopher.” Second, changes to internet hardware gradually made Gopher less appealing. As put by McCahill, Gopher was designed within “the limits of what the technology (at the time) could do.” It was deliberately text rich because images were slow to load on the comparatively slow modems of the early 1990s. The decision to prioritize text made Gopher relatively fast while the more image-oriented World Wide Web languished in slow speeds (the “World Wide Wait”). However, by 1994 improvements in modem technology had turned this asset into a liability.'

There is something amusing that the kernel maintainer most outraged by the whole thing is the guy who spends time changing the kernel to cripple OpenZFS.

>the other three (1, 2, 3) contained real bugs. None of those three were accepted by maintainers

So was the entire point of the paper false (or worse, lie)?

After doing some academic research I have a sour taste in my mouth for it, and this makes it even worse. Disappointing from UMN.

Given high number of buggy patches being accepted it seems kernel developers could use bug-bounty program.

I'll insert the bugs, and you can fix them, and we'll make bank together!

So the paper is not being published? Then what was the whole point of the research

They were forced to retract the paper as a result of this debacle.

The point was to get a paper published. That's it.

> [LWN subscriber-only content]

I'm guessing you weren't supposed to share this link?

right below that it says "The following subscription-only content has been made available to you by an LWN subscriber."

feature, not bug

I'm so very happy that's a feature, I subscribed to LWN a while back from reading some subscriber only links on HN.

LWN links are intentionally shareable. See the "Welcome .." box at the top:

> The following subscription-only content has been made available to you by an LWN subscriber.

FYI: the owner of lwn.net is on record as being ok with people widely sharing subscriber only content links.

When (as a subscriber) you make such a link, it says that if such links are "abused", the ability to make them may go away. Having the occasional article posted to HN seems to be OK with them (or they probably would have added a specific request not to post them to news aggregation sites). It's likely a wholesale "Free LWN for all" page with a weekly subscriber link to all the articles they're worried about.

Nope. LWN built the feature that subscribes can share links as a feature. If you subscribe, you can share.

LWN is a very fair and ethical organization. This struck what felt to them (and to much of the community) as a good balance.

The key take away, for me, has been that the Foundation that sent the demand letter does not have the balls to grant Stupid Prize to those that so diligently tried to win it.

A good demand letter announcing the winning of the Stupid Prize would have been to tell the university that it would be banned until it:

* fires the assistant professor

* terminates all the students that participated

with a note that should any of those students or a professor go to a different university that university would be banned as well.

Had that price would have been awarded it would have definitely made into future ethics classes.

Key point:

>>"kernel maintainers (and maintainers of many other free-software projects) are overworked and do not have the time to properly review every patch that passes through their hands. They are, as a result, forced to rely on the trustworthiness of the developers who submit patches to them. The kernel development process is, arguably, barely sustainable when that trust is well placed; it will not hold together if incoming patches cannot, in general, be trusted. "

Yet these UMN "researchers" deliberately chose to violate that trust.

Are they so ethically clueless and arrogant that they didn't think to review the plan? Did they hold any kind of ethical review and pass it, or fail it and decide to proceed anyway?

In any case, they've now alerted the entire world that the Linux dev process and OS dev processes in general are incredibly vulnerable to malicious actors.

This vulnerability is also shown by another #1 HN story[1]

[1] https://blog.netlab.360.com/stealth_rotajakiro_backdoor_en/

How does the netlab link have anything to do with Linux development processes?

>> "... a backdoor targeting Linux X64 systems, a family that has been around for at least 3 years."

The point is that OS systems fundamentally depend on the trustworthiness of the contributors and the diliginece and bandwidth of the maintainers.

Both are examples showing that the diligence and bandwidth is not infinite, and can be relatively easily overwhelmed or outmaneuvered.

The UMN hack showed how easily the trust can be violated, and the netlab 3 year lifetime before discovery shows how easily flaws can stay hidden.

The saying is "many eyes make shallow bugs". In an ideal case and with systems that are small relative to the body of people maintaining and actively scrutinizing it, that's true. The reality is that the scale of Linux and most OS is now well beyond the set of people scrutinizing it. How much source code did you review before you installed your latest build?

The "backdoor" is a program running on Linux. It's not a modification to any system component. "will run arbitrary binaries" is not an issue with lack of trustworthiness. (The way it came onto that system might be, but we don't know anything about that)

You are confused about the kernel vs. userland.

> They failed in their effort to deliberately insert bugs, but were able to inadvertently add dozens of them. ... kernel maintainers (and maintainers of many other free-software projects) are overworked and do not have the time to properly review every patch that passes through their hands ...code going into the kernel is often not as well reviewed as we like to think.

Sounds like there’s some room for improvement in the process of how lighter weight contributions are introduced, reviewed, and land in the kernel.

Perhaps there is a technical solution that would help ease the load off maintainers and shift some of the burden to patch authors.

—

When I find myself in times of trouble / mother Mozilla speaks to me / whisper words of wisdom / don't use C.

And in my hour of darkness / Rust is installed in my system tree / emitting tokens of wisdom / don't use C.

And then the broken hearted people / maintaining kernel code agree / Rust's safety is the answer / don't use C.

For though they may be parted / Rust will prevent Use After Fee / they will see the answer / don't use C.

And when the code is cloudy / the borrow checker confronts me / thou shall specify reference lifetimes / don't use C.

I wake up to the sound of safe code / not one vuln surrounding me / rust is in the kernel / no more C.

Rust doesn’t magically make your code bug free. The fixes/bugs you reference are highly unlikely to be all memory management related (eg use-after-free), and you can still do unsafe things in Rust even with memory.

Of course you can. But it is much harder. I'm just having some fun.

Anecdotally, Rust coerces you into writing sound code and really helps break some destructive habits that C breeds. I rarely need to debug Rust code and when I do the bugs are logic errors not memory errors. It's a noticeable difference. For lightweight contributions to the kernel and "peripheral" contributions (where some big company writes a massive messy driver because the market forces their hand.. not because they enjoy curating and actively helping to maintain linux), the type of discipline Rust enforces is invaluable.

Also, what do you mean that Rust won't solve use after free? The whole point of the borrow checker is tracking and enforcing reference lifetimes in order to prevent using a pointer to memory that's been dropped from scope and no longer has an owner (has been freed). Sure it can't prevent all issues magically just yet (there are limitations) but it's a positive force in the right direction.

Rust forces developers to do upfront what is usually relegated to careful code review. You're forced to think about the memory implications of your code. If the issue is that we can't thoroughly review the abundance of code submitted to the kernel, then e.g. requiring that, unless justified, new patches shall land in safe rust, seems like it would directly address the core issue that there aren't enough eyes on the code. Obviously it's more nuanced than that, there's existing code you can't just say "all new contributions must be rust".. the example is just illustrative.

The existing proposal and work on carefully incorporating rust into the kernel is super awesome. And I'm excited!

Rust and other languages with strong type systems don't magically make your code bug free but their type systems are more expressive.

If used correctly this can make all sorts of states unwanted program states unrepresentable. Rust's shining feature is its linear types but that doesn't mean the only kinds of bugs it eliminates are memory management related.

Reply on news.ycombinator.com