Linux Foundation Issues Frosty Final Judgment in UMN Scandal

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:

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.

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