Yeah, it is a bit disrespectful for kernel maintainers without gaining their approvals ahead of time.

Holy cow!! I&#x27;m a researcher and don&#x27;t understand how they thought it would be okay to not do an IRB, and how an IRB would not catch this. The linked PDF by the parent post is quite illustrative. The first few paras seem to be downplaying the severity of what they did (did not introduce actual bugs into the kernel) but that is not the bloody problem. They experimented on people (maintainers) without consent and wasted their time (maybe other effects too .. e.g. making them vary of future commits from universities)! I&#x27;m appalled.

In any university I&#x27;ve ever been to, this would be a gross violation of ethics with very unpleasant consequences. Informed consent is crucial when conducting experiments.If this behaviour is tolerated by the University of Minnesota (and it appears to be so) then I suppose that&#x27;s another institution on my list of unreliable research.I do wonder what the legal consequences are. Would knowingly and willfully introducing bad code constitute a form of vandalism?

In this post they say the patches come from a static analyser and they accuse the other person of slander for their criticisms&gt; I respectfully ask you to cease and desist from making wild accusations that are bordering on slander.&gt; These patches were sent as part of a new static analyzer that I wrote and it&#x27;s sensitivity is obviously not great. I sent patches on the hopes to get feedback. We are not experts in the linux kernel and repeatedly making these statements is disgusting to hear.( <a href="https:&#x2F;&#x2F;lore.kernel.org&#x2F;linux-nfs&#x2F;YH%2FfM%2FTsbmcZzwnX@kroah.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lore.kernel.org&#x2F;linux-nfs&#x2F;YH%2FfM%2FTsbmcZzwnX@kroah...</a> )How does that fit in with your explanation?

They apparently didn&#x27;t consider this &quot;human research&quot;As I understand it, any &quot;experiment&quot; involving other people that weren&#x27;t explicitly informed of the experiment before hand needs to be a lot more carefully considered than what they did here.

&gt; You do not experiment on people without their consent.Exactly this. Research involving human participants is supposed to have been approved by the University&#x27;s Institutional Review Board; the kernel developers can complain to it: <a href="https:&#x2F;&#x2F;research.umn.edu&#x2F;units&#x2F;irb&#x2F;about-us&#x2F;contact-us" rel="nofollow">https:&#x2F;&#x2F;research.umn.edu&#x2F;units&#x2F;irb&#x2F;about-us&#x2F;contact-us</a>It would be interesting to see what these researches told the IRB they were doing (if they bothered).Edited to add: 
From the link in GP: &quot;The IRB of UMN reviewed the study and determined that this is not human research (a formal IRB exempt letter was obtained)&quot;Okay so this IRB needs to be educated about this. Probably someone in the kernel team should draft an open letter to them and get everyone to sign it (rather than everyone spamming the IRB contact form)T

It does seem rather unethical, but I must admit that I find the topic very interesting. They should definitely have asked for consent before starting with the &quot;attack&quot;, but if they did manage to land security vulnerabilities despite the review process it&#x27;s a very worrying result. And as far as I understand they did manage to do just that?I think it shows that this type of study might well be needed, it just needs to be done better and with the consent of the maintainers.

Meh, this means a lot of viral social experiments on Youtube violate the Nuremberg code...

You could argue that they are doing the maintainers a favor. Bad actors could exploit this, and the researchers are showing that maintainers are not paying enough attention.If I were at the receiving end, I’d think checking a patch multiple times before accepting it.

&gt; indicating “looks good”I wonder how many zero days have been included already, for example by nation state actors...

&gt; You do not experiment on people without their consent.Applied strictly, wouldn’t every single A&#x2F;B test done by a product team be considered unethical?From a common sense standpoint, it seems to me this is more about medical experiments. Yesterday I put some of my kids toys away without telling them to see if they’d notice and still play with them. I don’t think I need IRB approval.

&gt; You do not experiment on people without their consent.By this logic eg. resume callback studies aiming to study bias in the workforce would be impossible.

But this is all a lie. If you read the linked thread you till see that they refused to admit to their experiment and even sent a new, differently broken patch.

There is sometimes an exception for things like interviews when n is only a couple of people. This was clearly unethical and it’s certain that at least some of those involved knew that. It’s common knowledge universities.

&gt; You do not experiment on people without their consent. This is in fact the very FIRST point of the Nuremberg code:&gt; 1. The voluntary consent of the human subject is absolutely essential.Which is rather useless, as for many experiments to work, participants have to either be lied to, or kept in the dark as to the nature of the experiment, so whatever “consent” they give is not informed consent. They simply consent to “participate in an experiment” without being informed as to the qualities thereof so that they truly know what they are signing up for.Of course, it&#x27;s quite common in the U.S.A. to perform practice medical checkups on patients who are going under narcosis for an unrelated operations, and they never consented to that, but the hospitals and physicians that partake in that are not sanctioned as it&#x27;s “tradition”.Know well that so-called “human rights” have always been, and shall always be, a show of air that lack substance.

&gt; You do not experiment on people without their consent. This is in fact the very FIRST point of the Nuremberg code:&gt; 1. The voluntary consent of the human subject is absolutely essential.The Nuremberg code is explicitly about medical research, so it doesn&#x27;t apply here.
More generally, I think that the magnitude of the intervention is also relevant, and that an absolutist demand for informed consent in all - including the most trivial - cases is quite silly.Now, in this specific case I would agree that wasting people&#x27;s time is an intervention that&#x27;s big enough to warrant some scrutiny, but the black-and-white way of some people to phrase this really irks me.PS: I think people in these kinds of debate tend to talk past one another, so let me try to illustrate where I&#x27;m coming from with an experiment I came across recently:To study how the amount of tips waiters get changes in various circumstances, some psychologists conducted an experiment where the waiter would randomly either give the guests some chocolate with the bill, or not (control condition)[0]
This is, of course, perfectly innocuous, but an absolutist claim about research ethics (&quot;You do not experiment on people without their consent.&quot;) would make research like this impossible without any benefit.[0] <a href="https:&#x2F;&#x2F;onlinelibrary.wiley.com&#x2F;doi&#x2F;epdf&#x2F;10.1111&#x2F;j.1559-1816.2002.tb00216.x" rel="nofollow">https:&#x2F;&#x2F;onlinelibrary.wiley.com&#x2F;doi&#x2F;epdf&#x2F;10.1111&#x2F;j.1559-1816...</a>

I&#x27;m confused - how is this an experiment on humans? Which humans? As far as I can tell, this has nothing to do with humans, and everything to do with the open-source review process - and if one thinks that it counts as a human experiment because humans are involved, wouldn&#x27;t that logic apply equally to pentesting?For that matter, what&#x27;s the difference between this and pentesting?

&gt;You do not experiment on people without their consent. This is in fact the very FIRST point of the Nuremberg code:&gt;1. The voluntary consent of the human subject is absolutely essential.Does this also apply to scrapping people&#x27;s data?

From their explanation:(3). We send the incorrect minor patches to the Linux community through email to seek their feedback.(4). Once any maintainer of the community responds to the email, indicating “looks good”, we
immediately point out the introduced bug and request them to not go ahead to apply the patch. At the
same time, we point out the correct fixing of the bug and provide our proper patch. In all the three cases,
maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. This
way, we ensure that the incorrect patches will not be adopted or committed into the Git tree of Linux.------------------------But this shows a distinct lack of understanding of the problem:&gt; This is not ok, it is wasting our time, and we will have to report this,&gt; AGAIN, to your university...------------------------You do not experiment on people without their consent. This is in fact the very FIRST point of the Nuremberg code:1. The voluntary consent of the human subject is absolutely essential.

&gt;&gt;&gt;On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits
Qiushi Wu, and Kangjie Lu.
To appear in Proceedings of the 42nd IEEE Symposium on Security and Privacy (Oakland&#x27;21). Virtual conference, May 2021.from <a href="https:&#x2F;&#x2F;www-users.cs.umn.edu&#x2F;~kjlu&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www-users.cs.umn.edu&#x2F;~kjlu&#x2F;</a>If the original research results in a paper and IEEE conference presentation, why not? There&#x27;s no professional consequences for this conduct, apparently.

The fact that they took the feedback last time and decided &quot;lets do more of that&quot; is already a big red flag.

The sign is to remind honest people that the lock is important, and we do not appreciate game playing here.

Their first suggestion to the process is pure gold:&quot;OSS projects would be suggested to update the code of conduct, something like “By submitting
the patch, I agree to not intend to introduce bugs”&quot;Like somebody picking your locks, and suggesting, &#x27;to stop this one approach would be to post a sign &quot;do not pick&quot;&#x27;

The study you’re quoting was a previous study by the same research group, from last year.

This does paint there side better, but it also makes me wonder if they&#x27;re being wrongly accused of this current round of patches? That clarification says that they only submitted 3 patches, and that they used a random email address when doing so (so presumably no @umn.edu).These ~200 patches from UMN being reverted might have nothing to do with these researchers at all.Hopefully someone from the university clarifies what&#x27;s happening soon before the angry mob tries to eat the wrong people.

I don&#x27;t think there have been any recent comments from anyone at U.Mn. So, back when the original research (happened last year) the following clarification was offered by Qiushi Wu and Kangjie Lu which atleast paints their research in somewhat better light: <a href="https:&#x2F;&#x2F;www-users.cs.umn.edu&#x2F;~kjlu&#x2F;papers&#x2F;clarifications-hc.pdf" rel="nofollow">https:&#x2F;&#x2F;www-users.cs.umn.edu&#x2F;~kjlu&#x2F;papers&#x2F;clarifications-hc....</a>That said the current incident seems to have gone beyond the limits of that one and is a new incident. I just thought it would be fair to include their &quot;side&quot;

Why don&#x27;t you read the article to find out? <a href="https:&#x2F;&#x2F;github.com&#x2F;QiushiWu&#x2F;QiushiWu.github.io&#x2F;blob&#x2F;main&#x2F;papers&#x2F;OpenSourceInsecurity.pdf" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;QiushiWu&#x2F;QiushiWu.github.io&#x2F;blob&#x2F;main&#x2F;pap...</a>

That’s about as useful as to answer the question “what is this company doing?” with “trying to make money”.

It&#x27;s a near perfect example of the dangers &#x27;publish or perish&#x27;.

What journal is going to accept a study like this if they haven&#x27;t obtained proper consent?

What any researcher needs to accomplish: more publications

Perhaps they wish to improve kernel security by pushing reviewers to be more careful.Or to prove its overall insecurity.

They apparently made a tool to find vulnerabilities that could later lead to bugs is a different patch was introduced.And for some insane reason, they decided to test if these kinds of bugs would be caught by inventing some and just submitting the patches, without informing anyone beforehand.<a href="https:&#x2F;&#x2F;www-users.cs.umn.edu&#x2F;~kjlu&#x2F;papers&#x2F;clarifications-hc.pdf" rel="nofollow">https:&#x2F;&#x2F;www-users.cs.umn.edu&#x2F;~kjlu&#x2F;papers&#x2F;clarifications-hc....</a>

Yikes, and what are they hoping to accomplish with this &quot;research&quot;?

Go hack a random organization without a vulnerability disclosure program in place and see how much goodwill you have. There is a very established best practice in how to do responsible disclosure and this is far from it.

&gt; 3) Getting the consent of the people behind the process would invalidate the results.This has not been a valid excuse since the 1950s. Scientists are not allowed to ignore basic ethics because they want to discover something. Deliberately introducing bugs into any open source project is plainly unethical; doing so in the Linux kernel is borderline malicious.

Getting specific consent from the project leads is entirely doable, and would have avoided most of the concerns.

You&#x27;re right, and it is depressing how negative the reaction has been here. This work is the technical equivalent of &quot;Sokalling&quot;, and it is a good and necessary thing.The thing that people should be upset about is that such an important open source project so easily accepts patches which introduce security vulnerabilities. Forget the researchers for a moment - if it is this easy, you can be certain that malicious actors are also doing it. The only difference is that they are not then disclosing that they have done so!The Linux maintainers should be grateful that researchers are doing this, and researchers should be doing it to every significant open source project.

1) They identified vulnerabilities with a process
2) They contributed the correct code after showing the maintainer the security vulnerability they missed. 
3) Getting the consent of the people behind the process would invalidate the results.

Yeah this actually seems more like sociological research except since it’s in the comp sci department the investigators don’t seem to be trained in acceptable (and legal) standards of conducting such research on human subjects. You definitely need prior consent when doing this sort of thing. Ideally this would be escalated to a research ethics committee at UMN because these researchers need to be trained in acceptable practices when dealing with human subjects. So to me it makes sense the subjects “opted out” and escalated to the university.

Besides that, if their &quot;research&quot; patch gets into a release, it could potentially put thousands or millions of users at risk.

&gt; The problem here is really that they’re wasting time of the maintainers without their approval.Not only that, but they are also doing experiments on a community of people which is against their interest and also could be harmful by creating mistrust. Trust is a big issue, without it it is almost impossible for people to work meaningfully together.

The problem here is really that they’re wasting time of the maintainers without their approval. Any ethics board would require prior consent to this. It wouldn’t even be hard to do.

&gt; While it is maybe &quot;scientifically interesting&quot;, intentionally introducing bugs into Linux that could potentially make it into production systems while work on this paper is going on, could IMO be described as utterly reckless at best.I agree. I would say this is kind of a &quot;human process&quot; analog of your typical computer security research, and that this behavior is akin to black hats exploiting a vulnerability. Totally not OK as research, and totally reckless!

Are there any measures being discussed that could make such attacks harder in future?

I&#x27;m confused. The cited paper contains this prominent section:Ensuring the safety of the experiment. In the experiment,
we aim to demonstrate the practicality of stealthily introducing
vulnerabilities through hypocrite commits. Our goal is not to
introduce vulnerabilities to harm OSS. Therefore, we safely
conduct the experiment to make sure that the introduced UAF
bugs will not be merged into the actual Linux code. In addition
to the minor patches that introduce UAF conditions, we also
prepare the correct patches for fixing the minor issues. We
send the minor patches to the Linux community through email
to seek their feedback. Fortunately, there is a time window
between the confirmation of a patch and the merging of the
patch. Once a maintainer confirmed our patches, e.g., an email
reply indicating “looks good”, we immediately notify the
maintainers of the introduced UAF and request them to not
go ahead to apply the patch.Are you saying that despite this, these malicious commits made it to production?Taking the authors at their word, it seems like the biggest ethical consideration here is that of potentially wasting the time of commit reviewers—which isn&#x27;t nothing by any stretch, but is a far cry from introducing bugs in production.Are the authors lying?

If they&#x27;re public IRC channels, do you mind mentioning them here? I&#x27;m trying to find the remnant. :)

I assume that having these go into production could make the authors &quot;hackers&quot; according to law, no?Haven&#x27;t whitehat hackers doing unsolicited pen-testing been prosecuted in the past?

I tangentially followed the debacle unfold for a while and this particular thread now has lead to heated debates on some IRC channels I&#x27;m on.While it is maybe &quot;scientifically interesting&quot;, intentionally introducing bugs into Linux that could potentially make it into production systems while work on this paper is going on, could IMO be described as utterly reckless at best.Two messages down in the same thread, it more or less culminates with the university e-mail suffix being banned from several kernel mailing lists and associated patches being removed[1], which might be an appropriate response to discourage others from similar stunts &quot;for science&quot;.[1] <a href="https:&#x2F;&#x2F;lore.kernel.org&#x2F;linux-nfs&#x2F;YH%2FfM%2FTsbmcZzwnX@kroah.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lore.kernel.org&#x2F;linux-nfs&#x2F;YH%2FfM%2FTsbmcZzwnX@kroah...</a>

The earlier patches could in theory be OK, but they also might combine with other or later patches which introduce bugs more stealthily. Bugs can be very subtle.Obviously, trust should not be the only thing that maintainers rely on, but it is a social endeavour and trust always matters in such endeavors. Doing business with people you can&#x27;t trust makes no sense. Without trust I agree fully that it is not worth the maintainer&#x27;s time to accept anything from such people, or from that university.And the fact that one can do damage with malicious code is nothing new at all. It is well known and nothing new that bad code can ultimately kill people. It is also more than obvious that I can ring the door of my neighbor, ask him or her for a cup of sugar, and blow a hammer over their head. Or people can go to a school and shoot children. Does anyone in his right mind has to do such damage in order to prove something? No. Does it prove anything? No. Does the fact that some people do things like that &quot;prove&quot; that society is wrong and trust and collaboration is wrong? What an idiocy, of course not!

I think that the patches that hit stable were actually OK, based on the apparent intent to &#x27;test&#x27; the maintainers and notify them of the bug and submit the valid patch after, but the thought process from the maintainers is:&quot;if they are attempting to test us by first submitting malicious patches as an experiment, we can&#x27;t accept what we have accepted as not being malicious and so it&#x27;s safer to remove them than to keep them&quot;.my 2c.

I wonder whether they broke any laws intentionally putting bugs in software that is critical to national security.

It more shows up a very serious problem with the incentives present in scientific research and a poisonous culture which obviously seems to reward malicious behavior. Science enjoys a lot of freedom and trust from citizens but this trust must not be misused. 
If some children playing throw fireworks under your car, or mix sugar into the gas tank, just to see how you react, this would have negative community effects, too. Adult scientists should be totally aware of that.This will lead in effect to that even valuable contributions from universities will be seen with more suspicion and will be very damaging in the long run.

By your logic, you allow recording people without their consent, experimenting on PTSD by inducing PTSD without people consent, or medical experimentation without the subject consent.Try to introduce yourself in the White House and when you get caught tell them &quot;I was just testing your security procedures&quot;.

&gt;It shows there is a problem with the review process if it is not catching 100% of this garbageWhat review process catches 100% garbage? It&#x27;s a mechanism to catch 99% of garbage -- otherwise Linux kernel would have no bugs.

I&#x27;m not sure what we learned. Were we under the impression that it&#x27;s impossible to introduce new (security) bugs in Linux?

The paper indicates that the goal is to prove that OSS in particular is vulnerable to this attack, but it seems that any software development ecosystem shares the same weaknesses. The choice of an OSS target seems to be one of convenience as the results can be publicly reviewed and this approach probably avoids serious consequences like arrests or lawsuits. In that light, their conclusions are misleading, even if the attack is technically feasible. They might get more credibility if they back off the OSS angle.

&gt; It shows there is a problem with the review process if it is not catching 100% of this garbage.Does that add anything new to what we know since the creation of the &quot;obfuscated C contest&quot; in 1984?

&gt; It shows there is a problem with the review process if it is not catching 100% of this garbage.It shows nothing of the sort. No review process is 100% foolproof, and opensource means that everything can be audited if it is important to you.The other option is closed source everything and I can guarentee that review processes let stuff through, even if its only &quot;to meet deadlines&quot; and you will unlikely be able to audit it.

Unable to follow the kernel thread (stuck in an age between twitter and newsgroups, sorry), but...did these &quot;researchers&quot; in any way demonstrate that they were going to come clean about what they had done before their &quot;research&quot; made to anywhere close to release&#x2F;GA?

It may be unethical from an academic perspective, but I like that they did this. It shows there is a problem with the review process if it is not catching 100% of this garbage. Actual malicious actors are certainly already doing worse and maybe succeeding.In a roundabout way, this researcher has achieved their goal, and I hope they publish their results. Certainly more meaningful than most of the drivel in the academic paper mill.

The same can be said about any software, really. It’s all too easy for a single malicious dev to introduce security bugs in pretty much any project they are involved.

It is worrying to consider that in all likelihood, some people with actually malicious motives, rather than clinical academic curiosity, have probably introduced introduced serious security bugs into popular FOSS projects such as the Linux kernel.Before this study came out, I&#x27;m pretty sure there were already known examples of this happening, and it would have been reasonable to assume that some such vulnerabilities existed. But now we have even more reason to worry, given that they succeeded doing this multiple times as a two person team without real institutional backing. Imagine what a state-level actor could do.

&gt; They could perform analysis of review&#x2F;acceptance by looking at past patches that introduced bugs without being the bad actors that they apparently are.Very good point.

There’s no research going on here. Everyone knows buggy patches can get into a project. Submitting intentionally bad patches adds nothing beyond grandstanding. They could perform analysis of review&#x2F;acceptance by looking at past patches that introduced bugs without being the bad actors that they apparently are.From FOSDEM 2014, NSA operation ORCHESTRA annual status report. It’s pretty entertaining and illustrates that this is nothing new.<a href="https:&#x2F;&#x2F;archive.fosdem.org&#x2F;2014&#x2F;schedule&#x2F;event&#x2F;nsa_operation_orchestra&#x2F;" rel="nofollow">https:&#x2F;&#x2F;archive.fosdem.org&#x2F;2014&#x2F;schedule&#x2F;event&#x2F;nsa_operation...</a> 
<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=3jQoAYRKqhg" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=3jQoAYRKqhg</a>

From <a href="https:&#x2F;&#x2F;lore.kernel.org&#x2F;linux-nfs&#x2F;CADVatmNgU7t-Co84tSS6VW=3NcPu=17qyVyEEtVMVR_g51Ma6Q@mail.gmail.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lore.kernel.org&#x2F;linux-nfs&#x2F;CADVatmNgU7t-Co84tSS6VW=3N...</a>,&gt; A lot of these have already reached the stable trees.If the researchers were trying to prove that it is possible to get malicious patches into the kernel, it seems like they succeeded -- at least for an (insignificant?) period of time.

&gt; It&#x27;s likely a university with professors that hate open source.This is a ridiculous conclusion. I do agree with the kernel maintainers here, but there is no way to conclude that the researchers in question &quot;hate open source&quot;, and certainly not that such an attitude is shared by the university at large.

At least in the university where I did my studies, each professor had their own way of thinking and you could not group them into any one basket.

&gt; (whereas we know that the strength of open source is its auditability, thus such bugs are quickly discovered and fixed afterwards)Which is why there have never been multi-year critical security vulnerabilities in FOSS software.... right?Sarcasm aside, because of how FOSS software is packaged on Linux we&#x27;ve seen critical security bugs introduced by package maintainers into software that didn&#x27;t have them!

&gt; Not a big loss: these professors likely hate open source.&gt; They are conducting research to demonstrate that it is easy to introduce bugs in open source...That&#x27;s a very dangerous thought pattern. &quot;They try to find flaws in a thing I find precious, therefore they must hate that thing.&quot; No, they may just as well be trying to identify flaws to make them visible and therefore easier to fix. Sunlight being the best disinfectant, and all that.(Conversely, people trying to destroy open source would not publicly identify themselves as researchers and reveal what they&#x27;re doing.)&gt; whereas we know that the strength of open source is its auditability, thus such bugs are quickly discovered and fixed afterwardsHow do we know that? We know things by regularly testing them. That&#x27;s literally what this research is - checking how likely it is that intentional vulnerabilities are caught during review process.

&gt; the strength of open source is its auditability, thus such bugs are quickly discovered and fixed afterwardsThat&#x27;s not true at all. There are many internet-critical projects with tons of holes that are not found for decades, because nobody except the core team ever looks at the code. You have to actually write tests, do fuzzing, static&#x2F;memory analysis, etc to find bugs&#x2F;security holes. Most open source projects don&#x27;t even have tests.Assuming people are always looking for bugs in FOSS projects is like assuming people are always looking for code violations in skyscrapers, just because a lot of people walk around them.

Not a big loss: these professors likely hate open source. [edit: they do not. See child comments.]They are conducting research to demonstrate that it is easy to introduce bugs in open source...(whereas we know that the strength of open source is its auditability, thus such bugs are quickly discovered and fixed afterwards)[removed this ranting that does not apply since they are contributing a lot to the kernel in good ways too]

Well, the decision can always be reversed, but on the outset I would say banning the entire university and publicly naming them is a good start. I don&#x27;t think this kind of &quot;research&quot; is ethical, and the issue needs to be raised. Banning them is a good opener to engage the instiution in a dialogue.

The university reviewed the &quot;study&quot; and said it was acceptable. From the email chain, it looks like they&#x27;ve already complained to the university multiple times, and have apparently been ignored. Banning anyone at the university from contributing seems like the only way to handle it since they can&#x27;t trust the institution to ensure its students are doing unethical experiments.

The University approved this research. How can one trust anything from that university now?

They reported unethical behavior to the university and the university failed to prevent it from happening again.

Well, shit happens. Imaging doctors working in organ transplants, and one of them damages trust of people by selling access to organs to rich patients. Of course that damages the field for everyone. And to deal with such issues, doctors have some ethics code, and in many countries associations which will sanction bad eggs. Perhaps scientists need something like that, too?

It is an extreme response to an extreme problem. If the other researchers don&#x27;t like the situation? They are free to raise the problem to the university and have the university clean up the mess they obviously have.

seems extreme. one unethical researcher blocks work for others just because they happen to work at the same employer? they might not even know the author of the paper...

What&#x27;s the recourse for them though? Just beg to have the decision reversed?

If this experience doesn&#x27;t change not only the behavior of U of M&#x27;s IRB but inform the behavior of every other IRB, then nothing at all is learned from this experience.Unless both the professors and leadership from the IRB aren&#x27;t having an uncomfortable lecture in the chancellor&#x27;s office then nothing at all changes.

&gt; Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota.That&#x27;s the university&#x27;s problem to fix.

If they wanted to do security research, they could have done so in the form of asking the reviewers to help; send them a patch and ask &#x27;Is this something you would accept?&#x27;, instead of intentionally sending malicious commits and causing static on the commit tree and mailing lists.

This is funny, but not at all a good analogy. There&#x27;s obviously not remotely as much public interest or value in testing the security of this professor&#x27;s private home to justify invading his privacy for the public interest. On the other hand, if he kept dangerous things at home (say, BSL-4 material), then his house would need 24&#x2F;7 security and you&#x27;d probably be able to justify testing it regularly for the public&#x27;s sake. So the argument here comes down to which extreme you believe the Linux kernel is closer to.

I wouldn&#x27;t be surprised if the good, conscientious members of the UMN community showed up at his office (or home) door to explain, in vivid detail, the consequences of doing unethical research.

The actual equivalent would be to steal his computer, wait a couple days to see his reaction, get a paper published, then offer to return the computer.

Put a flaming bag of shit on the doorstep, ring the doorbell, and write a paper about the methods Liu uses to extinguish it?

&gt; I think all patches have come from people currently being advised by Kangjie Liu[3] or Liu himself dating back to Dec 2018New plan: Show up at Liu&#x27;s house with a lock picking kit while he&#x27;s away at work, pick the front door and open it, but don&#x27;t enter. Send him a photo, &quot;hey, just testing, bro! Legitimate security research!&quot;

Not if the research involves the reviewing aspects of open source projects.

This research is specifically about getting patches accepted into open source projects, so that wouldn&#x27;t work at all.

Forking the kernel should be sufficient for research.

How thorough is IRB review? My gut feeling is that these are not necessarily the most conscientious or informed bodies. Add into the mix a proposal that conceals the true nature of what&#x27;s happening.(All of this ASSUMING that the intent was as described in the thread.)

It didn&#x27;t. Rather, it didn&#x27;t until after it had been conduct.<a href="https:&#x2F;&#x2F;www-users.cs.umn.edu&#x2F;~kjlu&#x2F;papers&#x2F;clarifications-hc.pdf" rel="nofollow">https:&#x2F;&#x2F;www-users.cs.umn.edu&#x2F;~kjlu&#x2F;papers&#x2F;clarifications-hc....</a>

I find it hard to believe this research passed IRB.

The goal is not penalizing or lumping everyone together. The goal is to have the issue fixed in the most effective manner. It&#x27;s not the Linux team&#x27;s responsibility to allow contributions from some specific university, it&#x27;s the university&#x27;s. This measure enforces that responsibility. If they want access, they should rectify.

One way to get everyone in a university on the same page is to punish them all for the bad actions of a few.  It appears like this won&#x27;t work here because nobody else is contributing and so they won&#x27;t notice.

I&#x27;d concur: the university is the wrong unit-of-ban.For example: what happens when the students graduate- does the ban follow them to any potential employers? Or if the professor leaves for another university to continue this research?Does the ban stay with UMN, even after everyone involved left? Or does it follow the researcher(s) to a new university, even if the new employer had no responsibility for them?

This was approved by the university ethics board so if trust of the university is by part because the actions of the students need to pass an ethics bar it makes sense to remove that trust until the ethics committee has shown that they have improved.

It&#x27;s the university that allowed the research to take place. It&#x27;s the university&#x27;s responsibility to fix their own organisation&#x27;s issues. The kernel has enough on their plate than to have to figure out who at the university is trustworthy and who isn&#x27;t considering their IRB is clearly flying blind.

that is completely irrelevant. they are acting under the university, and their &quot;Research&quot; is backed by university and approved by university&#x27;s department.if university has a problem, then they should first look into managing this issue at their end, or force people to use personal email ids for such purposes

Seems like a bit of a strong response. Universities are large places with lots of professors and people with different ideas, opinions, views, and they don&#x27;t work in concert, quite the opposite. They&#x27;re not some corporation with some unified goal or incentives.I like that. That&#x27;s what makes universities interesting to me.I don&#x27;t like the standard here of of penalizing or lumping everyone there together, regardless of they contribute in the past, now, in the future or not.

No, it&#x27;s totally okay to feel sorry for good, conscientious researchers and students at the University of Minnesota who have been working on the kernel in good faith. It&#x27;s sad that the actions of irresponsible researchers and associated review boards affect people who had nothing to do with professor Lu&#x27;s research.It&#x27;s not wrong for the kernel community to decide to blanket ban contributions from the university. It obviously makes sense to ban contributions from institutions which are known to send intentionally buggy commits disguised as fixes. That doesn&#x27;t mean you can&#x27;t feel bad for the innocent students and professors.

&gt; This is similar to initiating fluid mechanics experiments on the wings of a Lufthansa A320 in flight to Frankfurt with a load of Austrians.This analogy is invalid, because:1. The experiment is not on live, deployed, versions of the kernel.2. There are mechanisms in place for preventing actual merging of the faulty patches.3. Even if a patch is merged by mistake, it can be easily backed out or replaced with another patch, and the updates pushed anywhere relevant.All of the above is not true for the in-flight airline.However - I&#x27;m not claiming the experiment was not ethically faulty. Certainly, the U Minnesota IRB needs to issue a report and an explanation on its involvement in this matter.

This is not responsible research. This is similar to initiating fluid mechanics experiments on the wings of a Lufthansa A320 in flight to Frankfurt with a load of Austrians.There are a lot of people to feel bad for, but none is at the University of Minnesota. Think of the Austrians.

It&#x27;s important to note that they used temporary emails for the patches in this research. It&#x27;s detailed in the paper.The main problem is that they have (so far) refused to explain in detail how the patches where reviewed and how. I have not gotten any links to any lkml post even after Kangjie Lu personally emailed me to address any concerns.

It definitely would suck to be someone at UMN doing legitimate work, but I don&#x27;t think it&#x27;s reasonable to ask maintainers to also do a background check on who the contributor is and who they&#x27;re advised by.

How could a single student or professor possibly achieve that? Under the banner of &quot;academic freedom&quot; it is very hard to get someone fired because you don&#x27;t like their research.It sounds like you&#x27;re making impossible demands of unrelated people, while doing nothing to solve the actual problem because the perpetrators now know to just create throwaway emails when submitting patches.

I don&#x27;t feel sorry at all. If you want to contribute from there, show that the rogue professor and their students have been prevented from doing further malicious contributions (that is probably at least: from doing any contribution at all during a quite long period -- and that is fair against repeated infractions), and I&#x27;m sure that you will be able to contribute back again under the University umbrella.If you don&#x27;t manage to reach that goal, too bad, but you can contribute on a personal capacity, and&#x2F;or go work elsewhere.

Later down thread from Greg K-H:&gt; Because of this, I will now have to ban all future contributions from
your University.Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota.EDIT: Searching through the source code[1] reveals contributions to the kernel from umn.edu emails in the form of an AppleTalk driver and support for the kernel on PowerPC architectures.In the commit traffic[2], I think all patches have come from people currently being advised by Kangjie Liu[3] or Liu himself dating back to Dec 2018. In 2018, Wenwen Wang was submitting patches; during this time he was a postdoc at UMN and co-authored a paper with Liu[4].Prior to 2018, commits involving UMN folks appeared in 2014, 2013, and 2008. None of these people appear to be associated with Liu in any significant way.[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;torvalds&#x2F;linux&#x2F;search?q=%22umn.edu%22" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;torvalds&#x2F;linux&#x2F;search?q=%22umn.edu%22</a>[2]: <a href="https:&#x2F;&#x2F;github.com&#x2F;torvalds&#x2F;linux&#x2F;search?q=%22umn.edu%22&amp;type=commits" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;torvalds&#x2F;linux&#x2F;search?q=%22umn.edu%22&amp;typ...</a>[3]: <a href="https:&#x2F;&#x2F;www-users.cs.umn.edu&#x2F;~kjlu&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www-users.cs.umn.edu&#x2F;~kjlu&#x2F;</a>[4]: <a href="http:&#x2F;&#x2F;cobweb.cs.uga.edu&#x2F;~wenwen&#x2F;" rel="nofollow">http:&#x2F;&#x2F;cobweb.cs.uga.edu&#x2F;~wenwen&#x2F;</a>

&gt; Despite the positive underlying reasonsI think that is thinking too kind of them. Sociopaths are often very well-versed to give &quot;reasons&quot; about what they do, but at the core it is powerplay.

This is ridiculously unethical research. Despite the positive underlying reasons treating someone as a lab rat (in this case maintainers reviewing PRs) feels almost sociopathic.

&gt; non-existent... static analysis .... Whats being done to address those issues?Static analysis is being done[1][2], in addition, there are also CI test farms[3][4], fuzzing farms[5], etc. Linux is a project that enough large companies have a stake in that there are some willing to throw resources like this at it.Human review is supposed to be done through the mailing list submission process. How well this works depends in my experience from ML to ML.[1] <a href="https:&#x2F;&#x2F;www.kernel.org&#x2F;doc&#x2F;html&#x2F;v4.15&#x2F;dev-tools&#x2F;coccinelle.html" rel="nofollow">https:&#x2F;&#x2F;www.kernel.org&#x2F;doc&#x2F;html&#x2F;v4.15&#x2F;dev-tools&#x2F;coccinelle.h...</a>[2] <a href="https:&#x2F;&#x2F;scan.coverity.com&#x2F;projects&#x2F;linux" rel="nofollow">https:&#x2F;&#x2F;scan.coverity.com&#x2F;projects&#x2F;linux</a>[3] <a href="https:&#x2F;&#x2F;cki-project.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cki-project.org&#x2F;</a>[4] <a href="https:&#x2F;&#x2F;bottest.wiki.kernel.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;bottest.wiki.kernel.org&#x2F;</a>[5] <a href="https:&#x2F;&#x2F;syzkaller.appspot.com&#x2F;upstream" rel="nofollow">https:&#x2F;&#x2F;syzkaller.appspot.com&#x2F;upstream</a>

Human review was done after the patch was merged into stable, hence reverting was necessary. I’m confused why these patches don’t get treated as merge requests and get reviewed prior to merging!

Not sure why you think they proved that. Human review was done on the same day the patch was submitted and pointed out that it&#x27;s wrong: <a href="https:&#x2F;&#x2F;lore.kernel.org&#x2F;linux-nfs&#x2F;20210407153458.GA28924@fieldses.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lore.kernel.org&#x2F;linux-nfs&#x2F;20210407153458.GA28924@fie...</a>

The bugs were found. Seems like it works to me.

this is a dangerous understanding of Rust.  Rust helps to avoid certain kinds of bugs in certain situations.  Bugs are very much possible in Rust and the scope of bugs usually depends more on the system than the language used to write it.

&gt;Whats being done to address those issues?Moving to rust to limit the scope of possible bugs.

Regardless of their methods, I think they just proved the kernel security review process is non-existent. Either in the form of static analysis or human review. Whats being done to address those issues?

Seems to me they exposed a vulnerability in the way code is contributed.If this was Facebook and their response was:
&gt; ~&quot;stop wasting our time&quot;
&gt; ~&quot;we&#x27;ll report you&quot;
the responses here would be very different.

This is no better. All it does is increase the size of the research team. You’re still doing research on non-consenting participants.

Should&#x27;ve at least sought approval from the maintainer party, and perhaps tried to orchestrate it so that the patch approver didn&#x27;t have information about it, but some part of the org did.In a network security analogy, this is just unsolicited hacking VS being a penetration test which it claims more so to be.

It&#x27;s an acronym - Person Leaving Our Newsgroup; Kill-filed.

No .. Linus can approve it on himself. Linus cannot approve such a thing on behalf of other maintainers.

If an actual maintainer (i.e. an &quot;insider&quot;) approves your bug, then you&#x27;re not testing the same thing (i.e. the impact an outsider can have), are you?

&gt; This took 1 min of thinking btw.QFT.

This wouldn&#x27;t really be representative. If people know they are being tested, they will be much more careful and cautious than when they are doing &quot;business as usual&quot;.

This is a good question. You would recruit actual maintainers, [edit: or whoever is your intended subject pool] (who would provide consent, perhaps be compensated for their time). You could then give them a series of patches to approve (some being bug free and others having vulnerabilities).[edit: specifying the population of a study is pretty important. Getting random students from the University to approve your security patch doesn&#x27;t make sense. Picking students who successfully completed a computer security course and got a high grade is better than that but again, may not generalize to the real world. One of the most impressive ways I have seen this being done by grad students was a user study by John Ousterhout and others on Paxos vs. Raft. IIRC, they wanted to claim that Raft was more understandable or led to fewer bugs. Their study design was excellent. See here for an example: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=YbZ3zDzDnrw&amp;ab_channel=DiegoOngaro" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=YbZ3zDzDnrw&amp;ab_channel=Diego...</a> ]

Probably ask the maintainers to consent and add some blinding so that the patches look otherwise legitimate.

Ask about this upfront, get consent, wait rand()*365 days and do the same thing they did. Inform people immediately after it got accepted.

Out of curiosity, what would be an actually good way to poke at the pipeline like this? Just ask if they&#x27;d OK a patch w&#x2F;o actually submitting it? A survey?

So, for &quot;research&quot; you&#x27;re screwing around the development of one of the most widely used components in the computer world. Worse, introducing security holes that could reach production environments...That&#x27;s a really stupid behavior ...

Your feelings do not invalidate the results unfortunately.

&gt;they ultimately were trying to break the security of my computers.No they weren&#x27;t. They made sure the bad code never made it in. They are only guilty of wasting peoples time.

It&#x27;s more than that, if there is no consequences for this kind of action, we are going to get a wave of &quot;security researcher&quot; wannabes trying to pull similar bullshit.Ps: I have put security researcher in quotes because this kind of thing is not security research, it&#x27;s a publicity stunt.

How dare they highlight the vulnerability that exists in the process! The blasphemy!How about you think about what they just proved, about the actors that *actually* try to break the security of the kernel.

I feel somewhat similar. Since I am using Linux, they ultimately were trying to break the security of my computers. If I do that with any company without their consent, I can easily end up in jail.

I agree, I think they should be looking at criminal charges. This is the equivalent of getting a job at Ford on the assembly line and then damaging vehicles to see if anyone notices.  I&#x27;ve been in software security for 13 years and the &quot;Is Open Source Really Secure&quot; question is so over done. We KNOW there is risk associated with open source.

I believe as a user of the kernel the warranty exclusion in GPLv2 means you have no legal recourse:&gt; 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND&#x2F;OR OTHER PARTIES PROVIDE THE PROGRAM &quot;AS IS&quot; WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.<a href="https:&#x2F;&#x2F;www.gnu.org&#x2F;licenses&#x2F;old-licenses&#x2F;gpl-2.0.en.html" rel="nofollow">https:&#x2F;&#x2F;www.gnu.org&#x2F;licenses&#x2F;old-licenses&#x2F;gpl-2.0.en.html</a>..which is generally a good thing even if it also protects clearly malicious actions like this.

As a user of the linux kernel, I feel legal action against the &quot;researchers&quot; should be pursued.

I doubt an university e-mail gives you significantly increased trust in the kernel community, since those are given to all students in all majors (most of which are of course much less competent at kernel development than the average kernel developer).

Why should an academic institution be afforded any extra trust in the first place?

That&#x27;s kind of the rub. They used a university email to exploit the trust afforded to them as academics and then violated that trust. As a result that trust was revoked. If they want to submit future patches they&#x27;ll need to do it with random email addresses and will be subject to the scrutiny afforded random email addresses.

The project is interesting, but how can they be so dumb as to post these patches under an @umn.edu address instead of using a new pseudonymous identity for each patch?!?I mean, sneakily introducing vulnerabilities obviously only works if you don&#x27;t start your messages by announcing you are one of the guys known to be trying to do so...

State-level actors &#x2F; Nation wide actors (fancy terms lately, heh) will not ask anyone for consent

Wasting the time of random open source maintainers who have not consented to your experiment to try to get your paper published is highly unethical; I don&#x27;t see why this is a bad faith interpretation.

To provide some parallel on how the research was carried about:I see it as similar to- allowing recording of people without their consent (or warrant),- experimenting on PTSD by inducing PTSD without people consent,- or medical experimentation without the subject consent.And the arguments about not having anyone know:Try to introduce yourself in the White House and when you get caught tell them &quot;I was just testing your security procedures&quot;.

The concept of the research is quite good. The way this research was carried out, is downright unethical.By submitting their bad code to the actual Linux mailing list, they have made Linux kernel developers part of their research without their knowledge or consent.Some of this vandalism has made it down into the Linux kernel already. These researchers have sabotaged other people&#x27;s software for their personal gain, another paper to boast about.Had this been done with the developers&#x27; consent and with a way to pull out the patches before they actually hit the stable branches, then this could have been a valuable research. It&#x27;s the way that the research was carried out that&#x27;s the problem, and that&#x27;s why everybody is hating on the researches (rather than the research matter itself).

There are two separate issues with this story.One is that what the researchers did is beyond reckless. Some of the bugs they&#x27;ve introduced could be affecting real world critical systems.The other issue is that the research is actually good in proving by practical means that pretty much anyone can introduce vulnerabilities into software as important and sensitive as the Linux kernel. This hurts the industry confidence that we can have secure systems even more than it already is.While some praise may be appropriate for the latter, they absolutely deserve the heat they&#x27;re getting for the former. There may be many better ways to prove a point.

With that logic you can conduct research on how easy it is to rob elderly people in the street, inject poison in supermarket yogurts, etc.

It is not hard to point a gun at someone&#x27;s head.But let&#x27;s assume your girlfriend points an (unknown to you) empty gun at your head, because she wants to know how you will react. What do you think is the appropriate reaction?

Researcher(s) shows that it&#x27;s relatively not hard to introduce bugs in kernelHN: let&#x27;s hate researcher(s) instead of processWow.Assume good faith, I guess?

It matters for the sake of understanding what was going on, and why the issues weren&#x27;t caught in review.

Does it matter? They intentionally used their position as a university to push patches with malicious intent through.

Can someone explain what the kernel bugs were that were introduced, in general terms?

Nothing is perfect, but is it better than not having any eyes? If anything, this shows that more eyes is needed.

They were only banned after accusing Greg of slander after he called them out on their experiment and asked them to stop. They were banned for bring dishonest and rude.

&gt; A lot of people claim that there&#x27;s a lot of eyes on the codeAnd they are correct. Unfortunately sometimes the number of eyes is not enough.The alternative is closed source, which has prove to be orders of magnitude worse, on many occasions.

&gt; A lot of people claim that there&#x27;s a lot of eyes on the code.Eric Raymond claimed so, and a lot of people repeated his claim, but I don&#x27;t think this is the same thing as &quot;a lot of people claim&quot; -- and even if a lot of people claim something that is obviously stupid, it doesn&#x27;t make the thing less obviously stupid, it just means it&#x27;s less obvious to some people for some reasons.

&gt; but nobody thought so anywayA lot of people claim that there&#x27;s a lot of eyes on the code and thus introducing vulnerabilities is unlikely. This research clearly has bruised some egos bad.

&gt; They just proved that OSS is not military-grade...As if there is some other software that is &quot;military-grade&quot; by the same measure? What definition are you using for that term, anyway?

I assume they don&#x27;t use the bleeding edge though

&gt; They just proved that OSS is not military-grade , but nobody thought so anyway...and yet FOSS and especially Linux is very widely used in military devices including weapons.Because it&#x27;s known to be less insecure than most alternatives.

I guess someone had to do this unethical experiment, but otoh, what is the value here? There&#x27;s a high chance someone would later find these &quot;intentional bugs&quot; , it&#x27;s how open source works anyway. They just proved that OSS is not military-grade , but nobody thought so anyway

&gt;&gt; <a href="https:&#x2F;&#x2F;www-users.cs.umn.edu&#x2F;~kjlu&#x2F;papers&#x2F;clarifications-hc.pdf" rel="nofollow">https:&#x2F;&#x2F;www-users.cs.umn.edu&#x2F;~kjlu&#x2F;papers&#x2F;clarifications-hc....</a>&quot;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.&quot;

There is a sea of difference between A&#x2F;B testing your own property, and maliciously introducing a bug on a critical piece of software that&#x27;s running on billions of devices.

Isn&#x27;t a&#x2F;b testing usually things like changing layout or two things that....work as opposed to bugs?

I don&#x27;t quite understand the outrage. Quite sure most HN readers were doing&#x2F;involved in similar experiments one way or another. Isn&#x27;t A&#x2F;B testing an experiment on consumers (people) without their consent?

The next link is one hyperlink buried in the middle of the wall of text, and simply appends the new message to the existing one. It also differentiates between prev and parent?It&#x27;s super unclear.

Just keep hitting the &quot;next&quot; link to follow the thread.

Scroll down to the &quot;thread overview&quot;. There you can see the thread summarized in a tree layout, which makes more sense since asynchronous discussion isn&#x27;t typically linear.The current message in the tree is highlighted with the indicator &quot;[this message]&quot;; you can see replies branch out below it and parent messages above it.

Is there a more readable version of this available somewhere? I really struggle to follow the unformatted mailing list format.

I have no clue what you try to say, sorry.

&gt; Someone does voluntary work and people think that gives them some ethical privilege to be asked before someone puts their work to the test?Yes. Someone sees the work provided to the community for free and thinks that gives them some ethical privilege to put that work to the test?

Pathetic, it did not work at all, they told em whenever they missed a planted bug.

Agreed, in fact the review process worked and now they are going to ban all contributions from that university, as it should be. I think it all worked out perfectly

I never said they can not stop reviewing the code.
They can do whatever the heck they want. I&#x27;m not gonna tell a volunteer what they can and can not do. They just as much dont need anyone&#x27;s consent to ignore submits as thous who submitting dont need their consent. Its voluntary, if you dont see a benefit you are free to stop, not free to tell other volunteers what to do and not to do.

Or you could cease to do the voluntary work for them, because they clearly are not contributing to your goals. This is what the kernel maintainers have chosen and they have just as much right to do so. And you can perfectly well do this with consent, there&#x27;s a wealth of knowledge from psychology and sociology on how you can run tests on people with consent and without invalidating the test.

Exactly, they are just seem mad and blame other for &quot;wrong doings&quot; instead of acknowledging that they need to improve.

A far better approach would be to study patch submissions and see how many bugs were introduced by the result of those patches being accepted and applied, without any interference of any kind.Problem with that is it&#x27;s a lot of work and they didn&#x27;t want to do it in the first place.

Ridiculous comparison indeed. There was no pen testing going on.
Submitted code does not attack or harming any running system and whoever uses is does so completely voluntary. I dont need anyone&#x27;s approval for that. The license already states that I&#x27;m not liable in any way for what you do with it.

&gt; They wanted to see how the review goes if they aren&#x27;t aware that someone is testing them. You cant do this with consent.Ridiculous. Does the same apply to pentesting a bank or a government agency. If you wanted to pentest these of course you&#x27;d get approval from an executive that has power to sanction this. Why would Linux development be an exception? Just ask GKH or someone to allow you to do this.

Someone does voluntary work and people think that gives them some ethical privilege to be asked before someone puts their work to the test?
Sure it would be nice to ask but at the same time it renders the testing useless. They wanted to see how the review goes if they aren&#x27;t aware that someone is testing them.
You cant do this with consent.The wasting time argument is nonsense too its not like they did this thousands of times and beside that, reviewing a intentional bad code is not wasting time is just as productive as reviewing &quot;good&quot; code and together with the patch-patch it should be even more valuable work. It not only or adds a patch it also make the reviewer better.Yeah it aint fun if people trick you or point out you did not succeed in what you tried to do. But instead of playing the victim an play the unethical human experiment card maybe focus on improving.

WTF? They are experimenting with people without their consent? And they haven&#x27;t been kicked out of the academic community????

&quot;you wouldn&#x27;t have allowed me to experiment on you if I&#x27;d asked first&quot;I&#x27;m shocked the researchers thought this wasn&#x27;t textbook a violation of research ethics - we talk about the effects of the Tuskegee Study on the perception of the greater scientific community today.This is a smaller transgression that hasn&#x27;t resulted in deaths, but when it&#x27;s not difficult to have researched ethically AND we now spend the time to educate on the importance of ethics, it&#x27;s perhaps more frustrating.

It could have been done similar to how typosquatting research was done for ruby and python packages. The owners of the package repositories were contacted, and the researchers waited for approval before starting. I wasn&#x27;t a fan of that experiment either for other reasons, but hiding it from everyone isn&#x27;t the only option. Also, &quot;you wouldn&#x27;t have allowed me to experiment on you if I&#x27;d asked first&quot; is a pretty disgusting attitude to have.

Well, yeah, but the priority here shouldn&#x27;t be to allow the researchers to do their work. If they can&#x27;t do their research ethically then they just can&#x27;t do it; too bad for them.

&gt;So many comments here refrain, “They should have asked for consent first”.The Linux kernel is a very large space with many maintainers. It would be possible to reach out to the leadership of the project to ask for approval without notifying maintainers and have the leadership announce &quot;Hey, we&#x27;re going to start allowing experiments on the contribution process, please let us know if you&#x27;d like to opt out&quot;, or at least work towards creating such a process to allow experiments on maintainers&#x2F;commit approval process while also under the overall expectation that experiments may happen but that *they will be reverted before they reach stable trees*.The way they did their work could impact more than just the maintainers and affect the reputation of the Linux project, and to me it&#x27;s very hard to see how it couldn&#x27;t have been done in a way that meets standards for ethical research.

Yeah we get to hold people who are claiming to act in good faith to a higher standard than active malicious attackers. Their actions do not comport with ethical research practices.

Ethics in research matters. You don&#x27;t see vaccine researchers shooting up random unconsenting people from the street with latest vaccine prototypes. Researchers have to come up with a reasonable research protocol. Just because the ethical way to do what UMN folks intended to do isn&#x27;t immediately obvious to you - doesn&#x27;t mean that it doesn&#x27;t exist.

So many comments here refrain, “They should have asked for consent first”. But would not that be detrimental to the research subject? Specifically, stealthily introducing security vulnerabilities. How should a consent request look to preserve the surprise factor? A university approaches you and says, “Would it be okay for us to submit some patches with vulnerabilities for review, and you try and guess which ones are good and which ones have bugs?” Of course you would be extra careful when reviewing those specific patches. But real malicious actors would be so kind and ethical as to announce their intentions beforehand.

I don&#x27;t understand why this isn&#x27;t a more widely-held sentiment. There&#x27;s been instance after instance of corporate espionage in Western companies involving Chinese actors in the past 2 decades.

Yeah, state-actor scale sabotage was one of my first thoughts. And it gives me no joy to contemplate it.Secondly, the researcher’s attitude sounds high and mighty - making process improvement suggestions when their own ethical compass is in question. Their “experiment” was “what would happen if...”. Well, bans happen. If one starts a fight don’t get indignant over a bloody nose, lol

I would check their ties to nation-state actors.In closed source, nobody would even check. Modern DevOps has essentially replaced manual code review with unit tests.

I hope USENIX et al ban this student &#x2F; professor &#x2F; school &#x2F; university associated with this work from submitting anything to any of their conferences for 10 years.This was his clarification
<a href="https:&#x2F;&#x2F;www-users.cs.umn.edu&#x2F;~kjlu&#x2F;papers&#x2F;clarifications-hc.pdf" rel="nofollow">https:&#x2F;&#x2F;www-users.cs.umn.edu&#x2F;~kjlu&#x2F;papers&#x2F;clarifications-hc....</a>...in which they have the nerve to say that this is not considered &quot;human research&quot;. It most definitely is, given that their attack vector is the same one many people would be keen on using for submitting legitimate requests for getting involved.If anything, this &quot;research&quot; highlights the notion that coding is but a small proportion of programming and delivery of a product, feature, or bugfix from start-to-finish is a much bigger job than many people like to admit to themselves or others.

It&#x27;s possible that they didn&#x27;t knew what they were doing ( approving of this project) -- not sure if this is better or worse.

Does the University of Minnesota have an ethical review board  or research ethics board? They need to be contacted ASAP.

I respectfully ask you to cease and desist from making wild accusations that are bordering on slander.Responding properly to that statement would require someone to step out of the HN community guidelines.

<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=I7Umw70Yulw" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=I7Umw70Yulw</a>

I&#x27;m not the one who is making them sound like the same thing. There are literally people in this thread, saying that &quot;wasting time&quot; is being &quot;disrespectful&quot; to the maintainers.

I don&#x27;t see how this is related. Being rude in tone, and wasting someone&#x27;s time, are different things. You make it sound like they are the same.But the opposite of what you propose is true. The maintainers are annoyed by others wasting their time in other cases as well as in this case - it&#x27;s coherent behavior. And in my opinion, it&#x27;s sensible to be annoyed when someone wasted your time - be it by lazily made patches or by intentionally broken patches.

It&#x27;s funny. When someone like RMS or ESR or (formerly) Torvalds is &quot;disrespectful&quot; to open source maintainers, this is called &quot;tough love&quot;, but when someone else does it, it&#x27;s screamed about like it&#x27;s some kind of high crime, with calls to permanently cancel access for all people even loosely related to the original offender.

“They introduce kernel bugs on purpose”