General > General Technical Chat
University of Minnesota Linux code security issues; banned and to be removed
magic:
They wouldn't have fired everybody if everybody rejected it. Besides, I'm not just talking tolerating it, but actually walking around and telling everyone it's a good idea. Linus wasn't doing the latter if memory serves me, Greg was :--
--- Quote from: ataradov on April 26, 2021, 10:31:40 pm ---But the spirit of CoC is not to be dicks to each other, and knowingly submitting malicious code pretty much falls into being a dick.
--- End quote ---
That's one student who did it.
And what can we say about all the developers who publicly accused other students of doing the same, instead of admitting that they are incompetent or lazy fools who failed to notice problems with patches for potential security vulnerabilities submitted by a bunch of kids?
:box:
Reminder: there is no obligation to be competent when you submit stuff. It's on the team to handle everything you throw at them. They cannot ban you for lack of experience, kernel development background or education, they cannot ban you for mental disability even.
ataradov:
--- Quote from: magic on April 27, 2021, 05:23:51 am ---And what can we say about all the developers
--- End quote ---
Nothing. When acting on behalf of an organization, the whole organization is suspect. They did not accuse anyone, they said that they don't know what to think and how many of those patches are intentionally buggy. Bug given the overall low value of the patches, it is easier to remove all of them.
--- Quote from: magic on April 27, 2021, 05:23:51 am ---Reminder: there is no obligation to be competent when you submit stuff. It's on the team to handle everything you throw at them.
--- End quote ---
Yes, but there is moral obligation to submit patches in good faith.
Again, bugs get through regularly. This is a known thing. That is unavoidable part of the development process.
But submitting the bugs intentionally is a good reason to be banned from ever submitting anything ever again.
Some people seem to think that is it possible to detect all errors, manually or automatically. It is not possible in practice. So everyone just has to do their best effort to catch whatever they can. And the reset would be found and debugged later on.
magic:
It is obvious that we could continue this back and forth about "trust in contributors" vs "security of the process" indefinitely, so I will just stop at the following.
--- Quote from: ataradov on April 27, 2021, 06:48:53 am ---They did not accuse anyone, they said that they don't know what to think and how many of those patches are intentionally buggy.
--- End quote ---
--- Quote ---I will now have to ban all future contributions from
your University and rip out your previous contributions, as they were
obviously submitted in bad-faith with the intent to cause problems.
--- End quote ---
--- Quote from: ataradov on April 27, 2021, 06:48:53 am ---Bug given the overall low value of the patches, it is easier to remove all of them.
--- End quote ---
Based on my quasi-random sampling of the mega-review thread, most reverted patches were found to be alright. Of course my random clicking on random message titles may have been biased by whatever factors and things may have changed since two days ago, ICBA to do a proper analysis.
madires:
--- Quote from: magic on April 27, 2021, 10:30:58 am ---
--- Quote from: ataradov on April 27, 2021, 06:48:53 am ---Bug given the overall low value of the patches, it is easier to remove all of them.
--- End quote ---
Based on my quasi-random sampling of the mega-review thread, most reverted patches were found to be alright. Of course my random clicking on random message titles may have been biased by whatever factors and things may have changed since two days ago, ICBA to do a proper analysis.
--- End quote ---
The removal of old patches is a security precaution because the re-review of them will take some time. With version control tools you can remove the patches quickly to return to an "untainted" state. My guess is that the good patches will be added again after kernel experts verified them.
From my understanding the bad patches didn't add any security issues and were just some nonsense, which is annoying enough to be angry. Additionally to breaking the trust in the university's contributions they also indicate a lack of due diligence of the kernel maintainers regarding security and QA. That process needs to be improved which won't be easy.
ataradov:
Well, it looks like the article was withdrawn and will not be presented. And the actual (non-malicious) patches would remain in place after additional review.
Although I personally would place a ban on any future contributions, at least for a few years, provided that there is no other way to hold them accountable.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version