Linux Foundation Issues Frosty Final Judgment in UMN Scandal

These Penguins appear to be celebrating
(Image credit: Shutterstock)

The Linux Foundation Technical Advisory Board has released its findings regarding the University of Minnesota's (UMN) contributions to the Linux kernel—including those related to the research projects that got the university banned from working on that kernel. The group also explained how the school might be able to earn some forgiveness, but it won't be easy.

A quick refresher: In mid-April, the Linux developer who oversees the kernel's stable channel, Greg Kroah-Hartman, banned the entire UMN system from contributing to the Linux kernel in response to a couple of the university's research projects that centered on purposefully introducing faulty code to the kernel. The situation quickly became a point of contention to many in the Linux developer community.

UMN's Department of Computer Science & Engineering apologized for the research, as did the assistant professor and the graduate students who conducted it, in the days following Kroah-Hartman's announcement. But the Technical Advisory Board still had to double-check every UMN-related contribution to the Linux kernel.

The board released its findings on Wednesday in an email to the Linux kernel mailing list. In the email, board member Kees Cook said the group had to re-review 435 commits, or code contributions, to the Linux kernel that were associated with UMN. Here's how Cook summarized the quality of those commits:

- commits found to be correct (349)
- commits found to be incorrect and in need of fixing (39)
- commits already fixed by later commits (25)
- commits that no longer matter (12)
- commits made before the research group existed (9)
- commits the author asked to have removed (1)

That means the vast majority of commits associated with UMN were benign—but that doesn't change the fact that the Technical Advisory Board had to devote a significant amount of time to re-reviewing that code. That time could have been better spent doing almost literally anything else related to the Linux kernel.

Cook also said "UMN must improve the quality of the changes that are proposed for inclusion into the kernel" following this controversy, and that the Technical Advisory Board "will create a document explaining best practices for all research groups to follow when working with the kernel (and open-source projects in general)."

The board recommended that the UMN CSE find an experienced developer who can help it improve the quality of its code, better understand the Linux community, and prevent controversial research from "getting beyond the idea stage." It also recommended a more thorough review process for proposed research projects.

"Until such a review process is put into place, it will be difficult to re-establish the trust between UMN and the kernel community, and patches from UMN will continue to find a chilly reception," Cook said in the email. "If UMN needs help to find such a developer or to set up an internal review process, the TAB will be glad to assist.  This is a role the TAB has played with many groups in the past."

Nathaniel Mott
Freelance News & Features Writer

Nathaniel Mott is a freelance news and features writer for Tom's Hardware US, covering breaking news, security, and the silliest aspects of the tech industry.

  • ginthegit
    Why would you ever give them another chance? This breach was unethical at the very least, and too many of the commits were needing fixing.
    Reply
  • coolitic
    ginthegit said:
    Why would you ever give them another chance? This breach was unethical at the very least, and too many of the commits were needing fixing.
    Because the Linux Foundation is soft, especially when it comes to PR.
    Reply
  • ginthegit
    coolitic said:
    Because the Linux Foundation is soft, especially when it comes to PR.

    Very possible. However, I think the reality will be that the University will never touvh the code again.
    Reply
  • John Lauro
    It's a University, so the turnover of most involved would be fairly short (years), and although some bad commits (<10%, not sure how you define as too many, that could be 1), most were found to be good. This was not a case of a repeated offender (although several commits by one group in the University), so probation is in order, but a ban would make little sense as individuals could still submit from personal accounts where there is even less accountability then where the University is hopefully dealing with the issue internally.
    Reply
  • Mpablo87
    Hard to believe
    They did it!!!
    Reply
  • velocityg4
    ginthegit said:
    Why would you ever give them another chance? This breach was unethical at the very least, and too many of the commits were needing fixing.

    I think it depends on who knew about it at the university when it was going on.

    If it was just the two graduate students with a boneheaded research project and the assistant professor approved it. Why should the university, especially that university system as a whole, be punished?

    If it was known about and condoned or approved by the department head. Then maybe the whole university. If it was known about and condoned by the dean. Then definitely.

    If two Google employees did this for research and an assistant manager approved. Without anyone higher up knowing. Should all commits from Google be removed?
    Reply