LWN: Comments on "Intentionally buggy commits for fame—and papers"

Intentionally buggy commits for fame—and papers

littoral — Tue, 04 May 2021 13:38:05 +0000

'Quite obviously the paradigm has finally changed from "assume the contribution is well-intended" to "assume the contribution is malicious". '

This is overdue. It should have been the paradigm as soon as the contributor community became too large for all its members to be known personally to the project gatekeepers - if not before even that point.

The fact that it has not been the paradigm means that the kernel is already stuffed with malicious code from NSA and other espionage agencies of various countries.
We'll probably never identify all of it.

Intentionally buggy commits for fame—and papers

nspattak — Mon, 03 May 2021 09:30:06 +0000

I understand that the ban on all university emails can be unfair to individual members of the university yet IMO it is fully justified. The university is responsible for the research being done there both in fame and in shame. If I am not mistaken, a paper was published last year, so in this particular case the university can not even claim that they were unaware of this research.

Intentionally buggy commits for fame—and papers

richardw — Sat, 01 May 2021 23:48:24 +0000

One might take the stance the research experiment was not ethical. Its a bit like intentionally putting debris on a busy highway and then reporting how many more accidents resulted.

Intentionally buggy commits for fame—and papers

roc — Tue, 27 Apr 2021 03:18:06 +0000

I was referring to this: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

> I apologize for the misleading abstract which did not show the details and caused many confusions and misunderstandings.

> Throughout the study, we honestly did not think this is human research, so we did not apply for an IRB approval in the beginning. We apologize for the raised concerns. This is an important lesson we learned---Do not trust ourselves on determining human research; always refer to IRB whenever a study might be involving any human subjects in any form.

> We would like to sincerely apologize to the maintainers involved in the corresponding patch review process; this work indeed wasted their precious time.

> * The work taints the relationship between academia and industry
> We are very sorry to hear this concern.

Intentionally buggy commits for fame—and papers

roc — Tue, 27 Apr 2021 03:17:07 +0000

I was referring to this: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

> I apologize for the misleading abstract which did not show the details and caused many confusions and misunderstandings.

> Throughout the study, we honestly did not think this is human research, so we did not apply for an IRB
approval in the beginning. We apologize for the raised concerns. This is an important lesson we
learned---Do not trust ourselves on determining human research; always refer to IRB whenever a study
might be involving any human subjects in any form.

> We would like to sincerely apologize to the maintainers involved in the corresponding
patch review process; this work indeed wasted their precious time.

> * The work taints the relationship between academia and industry
> We are very sorry to hear this concern.

hiring choices

roc — Tue, 27 Apr 2021 03:10:44 +0000

So you're backing off "don't hire anyone who has ever worked at UMN"?

LF should sue

GoodMirek — Mon, 26 Apr 2021 18:27:25 +0000

Thanks for the link. It indeed shed more light on IRB of UMN.

Intentionally buggy commits for fame—and papers

carORcdr — Mon, 26 Apr 2021 05:56:57 +0000

In a review of The Minnesota Daily,[1] there are seven 'articles' that include Linux references as of 2021-04-25:2200.[2] The most recent from the year 2008 (about an individual speaking with the surname Stallman). The publication's stated mission includes: 'to 1. Provide independent student journalism and comprehensive coverage of news, media and events that serve the public interest and inform the University of Minnesota community.[3] The Minnesota Daily's 'journalism' would seem to be neither comprehensive, nor serving the public interest by its omission of material 'news of the day'.[4] Maybe LWN's Corbet, Jake, et al., could show them what journalism actually entails, including inquiring why they have not reported on this news.
[1] https://mndaily.com/about-us/
The Minnesota Daily is a student-led media organization serving the University of Minnesota campus and surrounding community.
[2] Comp. sci. activist to talk computing freedom at U, October 20, 2008
University wastes millions on software for students, Jason Ketola, September 26, 2005
U-spawned technology start-up flourishes, Nathan Hall, October 28, 2003
Net: Well, friends,…, October 3, 2000
Microsoft’s global language: Beta version 1.0, September 19, 2000
Microsoft inhibits software competition, May 4, 2000
Microsoft findings offer hope to industry, November 8, 1999
[3] https://mndaily.com/about-us/
Mission
1. Provide independent student journalism and comprehensive coverage of news, media and events that serve the public interest and inform the University of Minnesota community.
[4] References omitted.

Intentionally buggy commits for fame—and papers

rgmoore — Mon, 26 Apr 2021 00:45:17 +0000

Kernel devs should try to work *with* researchers instead of banning them (again, I'm aware those specific researchers screwed up big time in this case).

Kernel developers have spent a lot of time working with researchers; there are a bunch of things in the kernel that were put there as a result of academic research. That includes security testing, e.g. the Coverity scanner. But working together is a two-way street. I haven't seen anything in the discussion of this issue that shows these researchers made any attempt to work with the kernel developers, and that really has to happen first. It seems extremely unlikely to happen in this case, considering how seriously the relationship has already been damaged.

Intentionally buggy commits for fame—and papers

mss — Sun, 25 Apr 2021 12:50:37 +0000

They have submitted an apology few hours ago:
https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2...

They insist that their patches weren't intentionally malicious (besides these three patches described in their paper), including the current "a new static checker" round.

Intentionally buggy commits for fame—and papers

anonymous_commenter — Sun, 25 Apr 2021 02:03:38 +0000

Now that I have more time (paperwork shipped), please (Jon Corbet if you moderate comments and bpearlmutter) let me address each individual points:

The grad student isn't allowed to use the editor (cannot use self as experimental subject). also Their officemate has the same PI, also cannot be use it (has interest in result).

Bias in the result. Yes, I agree that one these two winners of the 2005 Nobel prize (www.nobelprize.org/prizes/medicine/2005/summary/) infected himself with H. Pilori to validate his result but for one exception, there are a metric ton of examples not to follow. It's like N95 and N99 masks now despite mass vaccination against COVID-19. some, not vaccinated peoples refuse to wear masks.

Key bindings must pass relevant health-and-safety regulations.

Health and security at work, not only universities are subjects to these law, so does every other workplaces in most countries. The laws (including workplace health and security) are implemented after the facts because someone suffered.

Anyone trying it has to fill out five pages of paperwork (consent form) that lists risks like injuring wrist from repetitive stress injuries, paging through material might cause screen to flash light-and-dark which could trigger photosensitive epilepsy.

Ever had a vaccine? read the package insert. I agree that's lawyeresque writing about the common (sore arm not because of the vaccine but rather the method of application...read syringe administered by a human) and not so common (Guillain Barré syndrome and death which range from 1 in a few million to one in a billion). Same laws or lawyeresque CYA.

Data retention policy must be on file, including plans for security, access, withdrawl of consent, external data control officer, audits for compliance.

How many years are you required to keep your taxes paperwork on hand before being allowed to destroy them? Here (canucksland), it's 7 years and I can ask for the last 10 years of my taxes to be recalculated. Now human research, more so because it involve human, not just financial data.

Statistical analysis must be pre-specified. Study must be pre-registered with appropriate bodies.

Yes to both, it's part the Geneva convention after the nazi experiments done by Dr Mengeles. Remember, the law upon which IRB are subjected to are after the facts and among the factual evidence base are the nazi experiments. There's also the various charter of human rights.

Intentionally buggy commits for fame—and papers

Yueting — Sat, 24 Apr 2021 13:42:15 +0000

To my best knowledge, the UMN teams never disclosed exactly which patches/emails belong to the experiment work that is described in their paper. Thus, in my personal humble opinion, till now, most discussion about this topic is built on the top of the maintainers' best guess/analyses.

Intentionally buggy commits for fame—and papers

gregkh — Sat, 24 Apr 2021 07:49:05 +0000

No one has apologized to me, or the Linux kernel community, for putting me, and everyone else, in an "experiment" to detect if we can properly notice "known broken" patches or not.

Where did you see an apology to me and everyone else?

hiring choices

etbe — Sat, 24 Apr 2021 00:12:00 +0000

After 20 years of working your degree is irrelevant, it's your work history that counts.

Intentionally buggy commits for fame—and papers

roc — Fri, 23 Apr 2021 20:23:04 +0000

A university is a much more heterogenous place than most companies. Researchy ones have a bunch of different research groups operating almost completely independently. You have classes also operating mostly independently. And you have students doing their own thing, also independently.

I don't think anyone really wants to treat everyone in a university as having collective responsibility. That way lies an erosion of student freedom that could, ironically, have impeded the creation of Linux in the first place.

Linux development shouldn't become less open

ale2018 — Fri, 23 Apr 2021 17:56:10 +0000

> 4. Accept that no software is perfect, Linux will inevitably have security bugs, and you're just going to have to deal with them when they are discovered.

As a single user, small office, or even a company with a limited tech dept, one can only afford #4. The alternative choice, to pay for a doubtfully warranted OS, is not much better, and in addition has privacy implications which are becoming more and more stifling.

The NO WARRANTY statements in GPLv2 are meant to be a legal stamp to cover programmers' arse from arbitrary claims of damage. It doesn't describe the real intent. Here the mission is an OS that all people can depend on, software for the mankind if you look at it from an evolution viewpoint.

The fact that software development can be exposed to vandalism like wikipedia needs more consideration.

Intentionally buggy commits for fame—and papers

joey — Fri, 23 Apr 2021 14:56:11 +0000

Something I have not seen mentioned anywhere from the paper is this:

We submit three patches using a random Gmail account to the Linux community

So either the paper is not describing what they really did, or there may be other poisoned patches to worry about.

Intentionally buggy commits for fame—and papers

Yueting — Fri, 23 Apr 2021 13:28:02 +0000

[1]
Does anybody have the UMN lab's exact and complete actions list? It will be really helpful for cleaning up issues and clarify the situation.

[2]
It looks to me that the questions in the below twitters are not only validate, but also very urgent.
https://twitter.com/MortenLinderud/status/138484439783832...

[3]
Some random emails (not UMN emails) may also be used for the "experiment".
(https://lore.kernel.org/lkml/YIEqt8iAPVq8sG+t@sol.localdo...)
If so, other patches need to be re-reviewed besides those from the UMN emails.

Intentionally buggy commits for fame—and papers

wtarreau — Fri, 23 Apr 2021 11:44:05 +0000

> I want kernel developers to have tools and workflow that efficiently/easily identify bugs (whether intentional or not) and spend less time on something so boring.

There are tons of tools, but the very concept of "review" exists because at some point you need a human. And it turns out that a lot of tools and imposed processes can drain a lot of human time as well. In the end it's important to find a sweet balance of tools and processes that makes everyone work at their best efficiency.

Avoiding errors is pointless because they will always exist, and there are diminishing returns on the efforts you add. Instead what matters is that they're quickly spotted and fixed. Here the tools and automated tests in place are helping a lot.

Still more participants would be nice. If you don't review, why wouldn't you start ? Just spot a patch that you can read, from time to time, return some suggestions or respond with a "reviewed-by" so that nobody else spends time on it and you'll help by saving someone's valuable time. You don't necessarily need to be skilled on the subject if you can read code and be curious. It doesn't matter if you make a mistake once in a while (though not too often): if your work eliminates 90% of the someone else's work and requires to be fixed 10% of the time, it's already 81% saved!

Intentionally buggy commits for fame—and papers

wtarreau — Fri, 23 Apr 2021 11:36:19 +0000

The deep issue isn't indeed the name but the ability to create throw-away identities via random email addresses. Seeing foo12345@gmail.com doesn't please me, and it doesn't please me more to see "Phil Scott" or "Jonathan Mars" in front of it. During the discussion abount the PRNG last year with "George Spelvin" I had no idea this name was not correct, but it had a pretty short address that didn't look temporary at all, and that was sufficient to me to believe it wasn't a troll.

Intentionally buggy commits for fame—and papers

gmgod — Fri, 23 Apr 2021 11:31:57 +0000

And "they" will succeed...

Though I can't possibly condone the way things were done in this instance, identifying and quantifying how buggy commits are passing through review seems important when said review fails so evidently. I want kernel developers to have tools and workflow that efficiently/easily identify bugs (whether intentional or not) and spend less time on something so boring. This is not the case.

Kernel devs should try to work *with* researchers instead of banning them (again, I'm aware those specific researchers screwed up big time in this case). All the papers I can read on the subject are really frightening in terms of bug introduced and time-to-fix.

Intentionally buggy commits for fame—and papers

andy_shev — Fri, 23 Apr 2021 08:35:48 +0000

The point is that maintainers always have to question all commits under their area of interest. This research proves that it’s not always the case.

Intentionally buggy commits for fame—and papers

andy_shev — Fri, 23 Apr 2021 08:25:01 +0000

“Russian hackers” won’t publish a research, they will silently put malicious commits into the OSS projects.

Intentionally buggy commits for fame—and papers

fulke — Fri, 23 Apr 2021 08:23:14 +0000

His post http://wookware.org/name.html

Intentionally buggy commits for fame—and papers

elel — Fri, 23 Apr 2021 06:59:52 +0000

I would argue that questioning the work of the submitting organization as a whole is actually a good response and even a normal one when security flaws are discovered. This isn't an exact parallel but take for example the compromise of Solarwinds products last year. The initial finding was from a single victim of the compromise but it led to finding many other victims, the original compromise, and the added scrutiny found several other vulnerabilities in the company's products.

Intentionally buggy commits for fame—and papers

mathstuf — Fri, 23 Apr 2021 00:31:37 +0000

Ah, I wasn't aware of that. Handy to keep in the back of the mind for the future. In any case, it's not a hard error that block merging, so it's not a tall barrier (other than the robot warning about the "full name policy").

Intentionally buggy commits for fame—and papers

rgmoore — Thu, 22 Apr 2021 23:27:56 +0000

What they really mean isn't quite "give me your real name"; it's closer to "give me a legal identity that can be held accountable for your behavior". That could be an individual identity, or it could be the contributor's employer vouching for them. The key point is that contributions can come with legal responsibility, e.g. if someone tries to contribute code they don't have the copyright for. The project wants to be able to link that code to an individual who can bear legal responsibility if something like that happens. Otherwise, the project as a whole will bear responsibility.

Intentionally buggy commits for fame—and papers

anonymous_commenter — Thu, 22 Apr 2021 23:26:07 +0000

Where I worked (cognitive science), there has been computer based testing of subjects (both typical and atypical) which involved computer scientist teaming up with psych or neuroscientist to implement those computer based test and in those cases, yes, IRB approval was sought out which was a normal process (more for psych or neuro peoples) but in any cases, IRBs in most major research university do get exposure to the computer science side of it.

Here, I see two faults:

1-: not seeking IRB approval first.

2-: either (yes, I can play devil's advocate), the IRB rubberstamped the study after the fact or else, the paper author lied about seeking IRB approval. Please take my concern with a grain of salt and no more than that; I'm just fresh out of an exam which took me 5 hours 45 minutes and I have to deliver 2 terms paperwork for next Monday 11:59pm, one of which isn't started yet. Otherwise, I would investigate.

Intentionally buggy commits for fame—and papers

pabs — Thu, 22 Apr 2021 23:25:06 +0000

There is a Debian contributor whose legal name contains no spaces: Wookey

Linux development shouldn't become less open

NYKevin — Thu, 22 Apr 2021 23:10:42 +0000

That is beside the point.

There are, broadly speaking, two categories of organizations we might be talking about:

1. Those that contribute to the kernel in some way.
2. Those that merely use it.

Of course, "we send patches to LKML from time to time" does not entitle an organization to demand change; LKML is not some tech company's private property. But it does at least give them a little bit of credibility when they *ask* for such changes. They can plausibly say "Yes, this will cost more work, but we will help you do it, and we genuinely believe this is in everyone's best interests in the long run." Group #2, by contrast, may not even properly understand LKML's normal development practices, let alone the exact change they want to propose, and so if they complain that the current process is "insecure," it will be ignored. As a GPLv2 project, Linux is of course offered "WITH NO WARRANTY" etc., so ignoring such complaints is not wrong. In fact, those working in highly regulated industries are probably wrong to ignore this admonition. You're supposed to get devices and software approved by your regulatory body, not just download random warranty-free software off of the internet, right?

Ultimately, the people in group #2 only have so many options to choose from:

1. Audit and fuzz test Linux very aggressively to make sure that bugs and regressions don't make it in.
2. Use something that is not Linux.
3. Contribute to Linux and help make things better. The easiest way to start is probably to take the tests from option #1 and try to upstream them.
4. Accept that no software is perfect, Linux will inevitably have security bugs, and you're just going to have to deal with them when they are discovered.

Intentionally buggy commits for fame—and papers

roc — Thu, 22 Apr 2021 22:38:48 +0000

It's good that everyone is taking Linux kernel quality very seriously today. Let me (re)raise a few suggestions that will help, which are standard practice in other projects:

Use a system for tracking bug reports (especially regressions) that is more reliable than "email LKML and hope it gets noticed and not forgotten".

Expect every submitted code change to come with an automated test (that is run before any release), or an explanation as to why such a test is infeasible. Create test frameworks to systematically reduce occurrences of the latter case.

Enthusiastically adopt Rust where possible because it eliminates entire classes of pernicious bugs.

Intentionally buggy commits for fame—and papers

pbonzini — Thu, 22 Apr 2021 22:28:08 +0000

That's as much a failure of the C language as it is a failure of patch review.

Using a language without RAII is inexcusable.

Intentionally buggy commits for fame—and papers

roc — Thu, 22 Apr 2021 22:26:26 +0000

> apologize immediately and voluntatily disclose any other similar attempts that have not already been caught and reverted by G K-H and/or by the the resulting process.

They have apologised, and have said there aren't any other similar attempts.

Intentionally buggy commits for fame—and papers

pbonzini — Thu, 22 Apr 2021 22:19:00 +0000

Lots of people in Indonesia have only one name. Some might make up an English-sounding name just to please westerners, but it's a fairly large country to say that people with one name (whether by changing it or being born with one name one) aren't generally contributing to FOSS.

The issue: experiments on humans without their consent

roc — Thu, 22 Apr 2021 22:17:51 +0000

As I said, I agree their clarifications don't make their actions right.

Linux development shouldn't become less open

roc — Thu, 22 Apr 2021 22:13:24 +0000

Retreating to "they're just hobbyists"/"they're just volunteers" when kernel devs are challenged about unprofessional practices is a cop-out. Fortunately, I seldom see actual kernel devs using it.

LF should sue

hummassa — Thu, 22 Apr 2021 21:16:51 +0000

This tells me that a decision to ban UMN as contributors to any project, at least for the time being, is not as absurd and guilt-by-association as I thought it would be at first. No need to sue, just blacklist them.

Intentionally buggy commits for fame—and papers

ScienceMan — Thu, 22 Apr 2021 20:38:30 +0000

The right way for these reserachers to make up for this is to apologize immediately and voluntatily disclose any other similar attempts that have not already been caught and reverted by G K-H and/or by the the resulting process. The people involved should then volunteer to spend their time for the couple of years looking for and working out ways to detect and correct other such attempts by any known or unknown third parties. There has to be a period of service to the community to make up for this disservice - supervised, if necessary.

Intentionally buggy commits for fame—and papers

bfields — Thu, 22 Apr 2021 20:03:01 +0000

I agree that it looks like some of their patch submissions were careless.

My only claim is that we don't currently have evidence to accuse them of these additional patches being intentionally malicious.

Responses to Greg's mass revert also aren't turning up much of interest:

https://lore.kernel.org/lkml/20210421130105.1226686-1-gre...

A few are buggy but I can't tell if they're unusually so over all.

LF should sue

deater — Thu, 22 Apr 2021 17:54:22 +0000

the previous prominent IRB/ethics lapse at U of Minnesota (yes there was one) was fairly horrifying but the University more or less won the case by claiming that as a state institution they could not be sued. You can read up on it here: https://www.startribune.com/markingson-case-university-of...