University Banned From Contributing To Linux Kernel For Intentionally Inserting Bugs

[oiaohm]

AFAIC reviews find that most of the patches from the general email domain are valid fixes, and a smaller number just useless, while the number of really problematic ones is much, much smaller than 200. Yet it seems to include one from one of the authors of the paper, and patches from his own student(s).

With the risks full review is required. Its better lose a few hundred/thousand patches than have a few patches with intentional exploits.

[Sonadow]

The world is not fair. Greg KH move here is not unprofessional. You have the original paper that put in 3 patches that had to be fixed up that was done in a unsafe way. Yes formal complaint was done over the first paper because it was unsafe. Now there are 200+ more patches from that university that are crap.

University students are meant to have proper supervision. The Linux kernel due to how many critical things depend on the Linux kernel means its not a playground.

Really how many more cases of bad supervision has to be let slide. Hard reality here a University as a whole is responsible for the actions of their students and is responsible to punish those students or refer them for criminal charges in cases like this. Until the university deals with the problem cutting them off is the correct action as this is the second time. First time formal complaint second time complete block is justified. Third time the legal departments of the companies supporting Linux will get involved.

People wonder why there are not more attempts to put exploits in the Linux kernel anyone who has read what the response policy is will normally not do it particularly when you work out its a strike 3 is a few thousand multi nationals after your hide backed up by many governments. The progressively getting worse until you are bankrupt. Lot of ways intentionally adding an exploit to the Linux kernel is way more dangerous for you than working at Microsoft and adding an exploit intentionally to windows. Microsoft with windows will want to cover up to the public that it happened. Linux kernel since the source code is public the fact its happen is on the record now companies want their pound of flesh from next to you heart.

You are just fibbing now.

The kernel is an FOSS project. Anybody living in the world has the right to view the code and send patches or commits. It's the maintainers' job to make sure that the commits ar good and safe before merging them into the master branch.

That something like this could happen show just how utterly broken and dysfunctional the existing system is with regards to the maintenance of the kernel, and the professor and his student exposed it for what it really is.

[ssokolow]

The kernel is an FOSS project. Anybody living in the world has the right to view the code and send patches or commits. It's the maintainers' job to make sure that the commits ar good and safe before merging them into the master branch.

An open-source project is effectively a private venue, capable of banning people and enacting arbitrary rules within the limits of local anti-discrimination statutes.

Nobody has a right to have their patches be considered, just like no magazine or newspaper has an obligation to consider your submission. Your right is to make a fork or patchset if you don't like how the project is being managed.

[oiaohm]

The kernel is an FOSS project. Anybody living in the world has the right to view the code and send patches or commits. It's the maintainers' job to make sure that the commits ar good and safe before merging them into the master branch.

That something like this could happen show just how utterly broken and dysfunctional the existing system is with regards to the maintenance of the kernel, and the professor and his student exposed it for what it really is.

No the Linux kernel is not a FOSS project by what you describe. The Linux kernel is the "Benevolent dictatorship" model this is important to beware of because this not the broad FOSS define. No where in Linux kernel documentation does it describe itself as FOSS project.

https://www.kernel.org/doc/html/latest/process/code-of-conduct.html

Maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

The Linux kernel define of Contributor is important. Contributor is either a organisation or a individual. When you are a student at a University you are technically not a individual. As a student just like a employee /member of a any other organisation it your organisation responsibility to keep you in line or suffer the ban.

So to make the Linux maintainers job simple for review that everyone from particular university/company/organisation is just 1 contributor. Remember this rule also makes universities/companies/organisations sanction their students/employees/members for miss behaviour in ways the Linux kernel maintainer cannot.

When you or you organisation is a banned contributor by the code of conduct the kernel maintainers are not required to read your submits past that point at all. Wasting maintainers time with possible security flaw causing modifications is harmful.

Remember I said the Linux kernel is "Benevolent dictatorship" this is basically a dictator who will kill you for doing the wrong things but may listen to you either. Yes a "Benevolent dictatorship" is allowed to work in very broad strokes to problems like this.

They want wanted to see how the Linux kernel developers respond to parties insert flawed patches they are now seeing first hard. I guess its a bit of a surprise to them that the Linux kernel maintainer don't worry about individuals when there is a organisation that can punish the individual to target instead so forcing that organisation hand.

Banning of complete organisations or company for bad code of individual is nothing new to the Linux kernel. The only thing that is new here is that this is the first university to get hit by it.

There has been a critical failure to research Linux kernel history of response before going and poking it.

[pmorph]

That something like this could happen show just how utterly broken and dysfunctional the existing system is with regards to the maintenance of the kernel, and the professor and his student exposed it for what it really is.

We all know genuine bugs can slip in. Logically it follows that designed bugs can slip in as well. They could have just asked, if that much wasn't clear.

[oiaohm]

We all know genuine bugs can slip in. Logically it follows that designed bugs can slip in as well. They could have just asked, if that much wasn't clear.

There is a catch here. Genuine natural human screw ups turn out to be very hard to artificially replicate. Think pattern of a random event vs a non random. Designed bugs have non random behaviour to them.

So no it does not follow that genuine bugs get in that you will be able to design a bug and insert it with lower risk of getting caught. The unnatural look of the code of someone attempting to design a bug to add in is going to make it more delectable and more likely maintainer will not see it as human error so be very annoyed.

PS if you are submitting something tool generated to the Linux kernel mailing list you are meant to state that so that you don't end up banned because its not going to look like natural human generated code..

[pmorph]

So no it does not follow that genuine bugs get in that you will be able to design a bug and insert it with lower risk of getting caught.

Lower risk, higher risk, similar risk. Anyway, I don't see what previously unknown results they hoped to find with the number of collected samples, which in this setting must be rather low. I think they weren't really interested in the quality of the linux patch submit process or its problems at all, they just needed whatever large enough project to test their ideas upon. In a word, exploit

[oiaohm]

Lower risk, higher risk, similar risk. Anyway, I don't see what previously unknown results they hoped to find with the number of collected samples, which in this setting must be rather low. I think they weren't really interested in the quality of the linux patch submit process or its problems at all, they just needed whatever large enough project to test their ideas upon. In a word, exploit

By there past paper they did not understand how Linux kernel developers would respond either. The never considered that getting caught would cause the Linux kernel maintainer to take action against the university instead of them as individuals. A lot of open source projects will not bother going after individuals when there is a bigger group to hit that can apply force to the individual.

Submitting to the Linux kernel is a process of being vetted getting caught doing wrong things will have long term effects on peoples means to get employment.