University of Minnesota Linux "Hypocrite Commit" Researchers Publish Open Letter

[curfew]

I believe their apology and intent was genuine and I doubt this will happen again. Moreover, it was done to prove a point - which they did, and we could learn from it. If there was any ban instituted against them, it ought to be removed.

Based on what? Usually on regular forums such as this one, if you troll or break the rules, you'd get a ban. That ban be one day for first-time offenders, or it might be a week or a month for repeat offenders. So why would these fucktards earn to have their ban be lifted immediately? They have never been a useful resource for the Linux kernel development, or at least my understanding is that they ever only submitted these re-tarded patches to boost their own private careers not related to being actual Linux developers. They deserve to be banned at least for the whole of 2021 if not longer.

[oiaohm]

I believe their apology and intent was genuine and I doubt this will happen again. Moreover, it was done to prove a point - which they did, and we could learn from it. If there was any ban instituted against them, it ought to be removed.

Sorry apology from them is not good enough. There is a strict reason. When I did university qualifications first year first quater of IT qualifications BA there was a mandatory subject Ethics and Legal sorry that subject from 1994 because I dug out covered exactly what they did with different countries laws that it was possible go to jail. For 3 months of that course it was the constant you must have approval. This was also one of the few subjects I did where 100% right on the exam was mandatory as well. This was not a subject where if you failed you could come back next year and do it again it was failed change university because they were not having you back. Yes 1 question wrong in the exam of that subject it was by by being at that university. Mind you the subject did have a 99% pass rate not because the questions where easy. Its because the legal side is very much solid logic that you use a third party you need approval.

Remember these guys are students working to PHD or have PHD doing masters so they have their BA already so in theory if the University courses have been structured right they should have known better without question and never tried this. The fact they tried is a failure of the University how many more of their students have not been trained correctly.

This is not like some non qualified hacker working for security company doing stupid research. This is qualified people doing stupid research with qualifications that they should have known better. Yes if they had learnt correctly in their qualifications they would not need to-do apology now.

This is a case the university need give apology with statement in how their courses are going to change so they don't generate more people with this problem. Heck this could be a mandatory class for all existing students and free online course for prior students to attempt to clean up the mess.

[MartinN]

I believe their apology and intent was genuine and I doubt this will happen again. Moreover, it was done to prove a point - which they did, and we could learn from it. If there was any ban instituted against them, it ought to be removed.

[Keats]

Honestly, I'd be OK if I catch someone with a bottle of vodka in his coat, as long as it is wrapped with a printed paper that ahead of time clarifies this is just a test and the vodka would be returned if the attempt at theft was successful.

That's the most ridiculous things I've read all week. So theft should be allowed so long as the thief can find some way to claim that it was only a "test" and they intended to return what they stole at some indeterminate point in the future? Sorry, but unless you have explicit prior authorization from someone with the power to authorize such a thing, it's still theft and you're still going to prison.

There are situations that are morally grey, but this one is very much black and white, what the "researchers" did was criminal, plain and simple.

[paulocoghi]

This letter is obviously fake. If you don’t have the common sense to realize that surreptitiously submitting bugs for inclusion into the Linux kernel was a bad thing, then certainly you don’t have the capacity to feel sorry for doing it.

This is clearly a last ditch attempt to prevent the ban and patch reversion from taking place. All patches from them should be pulled. If there are real bugs, then investigate them and write new patches. This group is not trustworthy.

Exactly. I agree 100% that all their patches must be removed, and the reason is simple: they were lying all the time, and they will not start saying the truth instantly. If they allowed such serious behavior to begin with, they are definitely not trustworthy.

[oiaohm]

Except not entirely, because they didn't go through the full process to get the change merged in.

More importantly, they were use-after-free bugs, rather than backdoors. Still bad, but as we all know that bugs sometimes creep into the kernel, it's not surprising that someone deliberately trying to hide them is able to do so.

They explain this in their paper, which I checked specifically to see how far the faithless patches actually got.

https://lore.kernel.org/linux-nfs/YH5%[email protected]/

That was only the ones they mention in their paper. Other ones were not use after free but adding items that have performance effects.

There are more than 1 way to create a backdoor in a system.

Except not entirely, because they didn't go through the full process to get the change merged in. <<
This bit is important this means all the automated tools around the Linux kernel from Intel and others did not kick in and check their patches either. So they were only testing the human part of the Linux kernel many eyes not the automated tools part of the many eyes.

There is a important reason why the head maintainers need to be informed its not uncommon for someone to see some else patch then improve on it and then submit it themselves. They had the stupid idea there was no risk if they did not push their defective alterations all the way though. The Linux kernel maintainer know way better than that.

No matter how you look at these guys started messing with a system they don't understand and are most likely getting really shocked at how the Linux system is responding to them and how little they understood. Yes there is a case that one of their patches from the first paper had another developer pick it up and modify it and submit it without their knowledge completely to be picked up by the automated tools when he submitted it as defective.

If anything proper study of what happened to their patches from their first paper lead to to understand why the Linux kernel maintainers are pissed. They had no clue how dangerous what they were doing was and the planned controls in the paper if something went wrong were not going to work.

Intentionally introducing a bug in the Linux development process with the idea that you can decide if it enters mainline or not is foolishness to the extreme.

Only safe guard that is some what able to work is the Linux kernel 3 lead maintainers. Please note I said some what. Think of Ubuntu and its customised kernel or a android device with soc vendors customised kernel. Yes there are Linux kernel in use that contain patches cherry picked from the Linux kernel mailing list that have not been though the complete mainline Linux validation process.

The punishment for putting known unsafe patches in the Linux kernel mailing list can be quite extreme because there is insane amount of risk.

[bobdowling]

The most effective response would be to write a letter of complaint to their University Department’s Research Ethics Committee. These committees exist precisely to stop scenarios like this and they have the internal power to make life unpleasant for the rogue researchers. (I am assuming they did not get ethics committee approval.)

[coder]

The reason the kernel maintainers got so butt hurt over this is because it exposed the idiocy behind open source software. The whole "many eyes reviewing the source makes it more secure" has always been stupid and this proves it.

Except not entirely, because they didn't go through the full process to get the change merged in.

More importantly, they were use-after-free bugs, rather than backdoors. Still bad, but as we all know that bugs sometimes creep into the kernel, it's not surprising that someone deliberately trying to hide them is able to do so.

They explain this in their paper, which I checked specifically to see how far the faithless patches actually got.

[oiaohm]

The reason the kernel maintainers got so butt hurt over this is because it exposed the idiocy behind open source software. The whole "many eyes reviewing the source makes it more secure" has always been stupid and this proves it. If the researchers had not said anything no-one would have ever known.

Makes you wonder how many backdoors and bugs have been purposely added to various open source projects by supposedly trusted contributors.

No the reason why they got caught second time was the many eyes things. Of course there is the knowledge side to the many eyes on how well it works.

The research paper changed something that would be ignored as a common human error and not tracked to be taken as a serous problem to be tracked in case of repeating behaviour.

That the thing with git blame and other features found in modern day source management you can track to exactly who was the developer who introduced the bug. You see contributors cease to be trusted at different times because down the road those questionable patches they have been getting in have been recognised for what they are.

Its very much a false idea that no one would have ever known.

Many eyes thing is true over the long term due to the detail histories good source management tools keep and how those can be processed seeing what developers are the source of different security faults. Short term not as good.

Yes you can with the source histories see what developers are introducing what types of bugs. History is the big thing here if you don't learn from history you are doomed to repeat it. This is part of the open source world a flaw happens then items are put in place to detect this kind of problem.

https://news.sophos.com/en-us/2020/12/14/solarwinds-breach-how-to-identify-if-you-have-been-affected/

sophisticles being closed source does it make it immune to the supposedly trusted contributor problem or third party hack in problems. Closed source does remove the many eyes thing.

https://nakedsecurity.sophos.com/2021/03/30/php-web-language-narrowly-avoids-dangerous-supply-chain-attack/

Its not just the Linux kernel where we have seen the many eyes thing work. So basically those are two supply chain attacks the php open source one gets detected because of many eyes that open source has allowed and the solarwinds one is closed source and was missed. There is a trend that a supply chain attack is more likely to be detected in open source than closed source all due to the number of people who can look at the source.

This does not make the many eyes system 100 percent perfect. But there are enough supply chain attacks documented to say that many eyes reviewing is a mitigation factor.

Software development is a hostile world be it closed or open source.

The whole "many eyes reviewing the source makes it more secure" has always been stupid and this proves it.

This idea is not really based on broad research. This is you taking a jump of a cliff because this one paper matches you personal bias the broad research going back centuries disagrees with your idea that its stupid. The data on different supply chain attacks of the centuries say that many eyes reviewing security reduce supply chain attacks is better than limited individuals this is not restricted to source code/software development. So many eyes reviewing does make open source generally more secure than closed source for the same reasons why a many eyes review of a ports warehouse results in better security of the warehouse than a individual because the many eyes will look at the problem differently considering more possible issues so come up with better solutions and countermeasures.

The less diverse you solution review system is the more likely it will be defective. Remember the many eyes thing does also apply to how we calculate sample sizes for medical trials and the like to make sure there is enough exposure.

Please note I said generally more secure not absolutely secure. Many eyes is not a magic bullet that fixes everything but a factor that has to be considered.

The hard point with security is that is more often than not a probability not a hard black or white answer.

The large sample size data on many eyes always says its better security by probability. But there is always outlier risk like the table vs cash-register as a store owner where should you place your money. Yes there the highest probability says the cash register is the safer than the table for the money but the outlier event the criminal run in grabs the cash register and leaves the stack of money that was sitting on the table. Sophisticles the reality is the way you said many eyes is stupid would be saying that business should not put money in cash registers but leave it on the table because of the outlier risk of the thief steeling the cash register.

[sophisticles]

The reason the kernel maintainers got so butt hurt over this is because it exposed the idiocy behind open source software. The whole "many eyes reviewing the source makes it more secure" has always been stupid and this proves it. If the researchers had not said anything no-one would have ever known.

Makes you wonder how many backdoors and bugs have been purposely added to various open source projects by supposedly trusted contributors.