Intentionally buggy commits for fame and papers (2021) | Hacker News Reader

Intentionally buggy commits for fame and papers (2021)

lwn.net

42 pointsmmsc19 comments

Since it’s from 2021, does anybody has a follow-up on this? What happened to the researchers? Did something changed in the patch process to limit these attempts?

Linux Foundation TAB report: https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/ - bottom of the report made a recommendation each for UMN and the TAB

UMN statement: https://cse.umn.edu/cs/statement-computer-science-engineerin...

Here's the letter from the Linux Foundation:

https://www.zdnet.com/article/the-linux-foundations-demands-...

Full disclosure: it is from Mike Dolan, but I wrote a substantial part of it.

Yes, things did change.

1. UMN got pull on a "ban" list which means someone else has to review their proposals before they will be considered by the kernel community. The purpose is not to punish, but rehabilitate. So hopefully they'll get off the list (they may have already done so, I haven't checked recently).

2. The Linux Foundation and UMN had a formal meeting. The goal wasn't to hurt UMN, just to prevent recurrence. UMN agreed to ensure all CS faculty got training on Institutional Review Boards (IRBs), including the rules on experiments involving humans.

3. The Linux kernel now has a much clearer statement about research, here: https://www.kernel.org/doc/html/latest/process/researcher-gu...

Again, the goal was focused on resolving any issues and preventing recurrence. I don't know of any recurrence, so I think we can count these changes as a success.

As an alumn it’s pretty annoying to see UMN dragged through the mud by assholes trying to get papers, even a few years on.

We covered this back then on the #osspodcast:

Episode 269 – Do not experiment on the Linux Kernel

https://opensourcesecurity.io/2021/05/02/episode-269-do-not-...

Josh and Kurt talk about the University of Minnesota experimenting on the Linux Kernel. There’s a lot to unpack in this one, but the TL;DR is you probably don’t want to experiment on the kernel.

Yeah, my first reaction to this was "WTF, again?!". Then I noticed the date. Needs a (2021)

I'd tweak that statement. Experimenting on the kernel is fine. Experimenting on humans without their consent is not fine.

Previous discussion when this story originally broke:

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

It is obviously a valid research, as it proves a possible security flaws in the process. But on the other hand it is also obvious that kernel folks won’t entertain it unless it is just a technical matter. But we all know kernel community has been a very political space for a long time. Even Linus himself can not be excluded from it.

I find this research to be both ethical and necessary, and I think kernel devs decrying it as wasting their time are missing the point. They demonstrated the whole "with enough eyes all bugs are shallow" security model doesn't really work. If some of the best devs out there fall for bad patches, it can happen to any OSS project (and for that matter for prop code bases too, but there you at least have to go through the hurdle of being hired before your code is considered).

Why's it necessary? We already know that this method of software development, like all methods, isn't perfect if you pick a short enough timeframe.

Did you read the report? (<https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/>) Allow me to quote from it:

    Patch 3
    
    First email: Thu, 20 Aug 2020 22:44:57 -0500 (Fri, 21 Aug 2020 03:44:57 UTC)
    First reply: Fri, 21 Aug 2020 11:14:49 +0300 (Fri, 21 Aug 2020 08:14:49 UTC)
     https://lore.kernel.org/lkml/20200821034458.22472-1-acostag.ubuntu@gmail.com
    
    This patch was quickly recognized by a reviewer to be incorrect, and the
    reviewer offered up possible changes that the submitter could make in
    order to turn it into a correct change.  These suggestions were ignored
    by the submitter and no further changes were submitted in this area.
    
    The maintainer was attempting to mentor an obviously junior contributor,
    taking time to teach the developer what the proper thing to do here
    would be, and what is needed in order to have them create a
    contribution that would be acceptable.  The contributor knew that the
    patch was bad, showing that the researchers were willing to waste the
    resource that is in shortest supply in our community: the time of
    reviewers and maintainers.  Having this waste of an "effort of someone
    trying to teach another" be created by an educational institution was
    especially hurtful to the community and caused many of the bad feelings
    on the community's side, further amplified by not having any idea which
    patches out of the hundreds sent by UMN or from new contributors using
    gmail accounts might be intentionally bad.

    […]

    Summary of "Hypocrite Commits" patch attempts
    
    All patch submissions that were invalid were caught, or ignored, by the
    Linux kernel developers and maintainers.  Our patch-review processes
    worked as intended when confronted with these malicious patches.

As you can see, the time that was wasted was especially valuable, and the research did not demonstrate any such thing.

In which line of work or venue could a competent person with intentions like these NOT succeed in introducing subtle problems? If there were such a thing where someone could not possibly introduce a problem if they tried, what would that even look like? Certainly not an aspirational open source project. Maybe you couldn't do this with FAA regs or it would take too much time to build up the credibility to "commit code" there, or I guess for an extreme example the US Constitution, but most other things I can think of you can do something like this "study" and achieve similar meaningless results. Yes, people rely on other's goodwill and intentions to some degree when collaborating.

> Maybe you couldn't do this with […] for an extreme example the US Constitution,

The Eighteenth Amendment says hello.

Preventing the introduction of subtle bugs when making changes to a complex system is hard, even disregarding intent. I'd say it's easier to catch deliberately-malicious patches, because easy-to-predict failures are the easiest to catch.

Every law has subtle problems. This is about introducing subtle but serious and exploitable issues on purpose, and I wouldn't say the eighteenth amendment is anywhere near that territory.

Well, there's another example. It was deliberately exploited by other lawmakers, but I imagine the original issue was probably accidental.

The thirteenth amendment, while intended to abolish slavery, actually rendered state-sanctioned slavery explicitly constitutional (albeit, with extra steps); e.g. the Black Codes in certain states prohibited “vagrancy”, which (afaik) basically let them enslave anyone they could get a jury to agree wasn't “contributing to society” via “gainful employment”. This lead to the fourteenth amendment trying to patch this issue – not by forbidding slavery as punishment for a crime, but by requiring “equal protection”: in essence, states couldn't make laws that only applied to certain people.

I don't have any examples of exploitable issues being deliberately introduced to legislation, because generally, people in a position to introduce them don't have to be subtle about it. Perhaps the 11th Congress of the Russian Communist Party's creation of the position of General Secretary was an example, but I don't know if we know what happened there.

Before the thirteenth amendment to the US constitution, §4.2.3 permitted slavery and, arguably, implicitly required its enforcement even by states that outlawed slavery. That might count, seeing as many drafters were anti-slavery, and did not expect this clause to allow the 19th-century resurgence of slavery-powered plantations; whereas other drafters were pro-slavery, and presumably insisted upon this clause's inclusion.

(2021)

Added above. Thanks!

Umm, 2021.

Reply on news.ycombinator.com