General > General Technical Chat
University of Minnesota Linux code security issues; banned and to be removed
<< < (5/23) > >>
ataradov:

--- Quote from: magic on April 23, 2021, 10:05:21 pm ---A quick glance at responses to Greg's mass-revert shows that most stuff from that university was legit fixes.

--- End quote ---
The bad patches were also masqueraded as legit fixes. They just had unintended side effects.

And the removal is more of a deterrent. I'm sure most of that code is fully legit, but you don't want to encourage this type of childish and stupid behavior. It might turn into a stupid trend of trying to push bad code into the kernel in a more and more escalating ways.

In fact, I personally would cancel the conference talk too, just to signal to others that there is absolutely nothing to be gained from that.
bd139:

--- Quote from: DrG on April 23, 2021, 11:03:52 pm ---
--- Quote from: bd139 on April 23, 2021, 10:50:59 pm ---There’s no contributor contract as such so there’s no legal agreement in place. Usually your only agreement would be to surrender copyright to the project in some way. Thus you could roll up and steaming turd and drop the patch and if they accept it then it’s the maintainer’s funeral, which in this case it should be.

There is a lot of distraction here by the community from the fact that there is a massive vulnerability in the process. Imagine how many times that has been exploited potentially. There are a hell of a lot of contributors.

Both sides of this process are to blame.

The whole OpenBSD IPSEC and DARPA thing is another example of the plausible scenarios.

--- End quote ---

Do you think that there will be some substantial process changes as a result of this or a lot of saber rattling until the smoke clears and then business as usual...or something in between?

--- End quote ---

Loudest ego wins in 2021 and that appears to be the kernel team.

But adversaries know it’s a process vulnerability now so not acting would be socially irresponsible. Also this is now on everyone’s risk assessment and if it happened again the paid up vendors will be on the hook.

Could go either way but this is a massive “oh shit” moment that will affect the industry for years. Not immediately though!
ataradov:

--- Quote from: DrG on April 23, 2021, 11:03:52 pm ---Do you think that there will be some substantial process changes as a result of this or a lot of saber rattling until the smoke clears and then business as usual...or something in between?

--- End quote ---
I don't think anything substantial will change. The process as it is works fine for what it is. There is no way to improve it unless you are willing to invest more resources. And those resources should come from the parties benefiting from the improvements. If the companies using Linux in their products think that Linux community is not doing enough - they should invest more money, or even hire third-party reviewers.

I use Linux on my PCs and I'm personally fine with the Linux as it is. I don't think their model of development is flawed in any way here.

I would not ascribe Linux developers some grand social responsibility. They are just writing software. The responsibility lies on the users. If someone truly believes that malicious intent clause in the contract would prevent proprietary software from having bugs, then they are free to switch to that proprietary software.

And if as a result Linux sees significant drop in use, then they will have problem that they would have to address.
magic:
Things clearly don't work well if anyone signed off on their shit patches. And those who did have just been caught with their pants down. It's the whole point of review to catch errors, intentional or not.

Only if no one did, then the students have indeed wasted everybody's time for no gain and should have never published their paper out of embarrassment.

By the way, a few years ago many RAID0 SSD arrays lost data because of a buggy fix to a hypothetical bug that affected nobody, which ended up destroying every array every time trim was used on it. It's painfully obvious no one had even tested the alleged fix, and it got backported to all stable releases, thank you very much.

So it's not even the first time shit happens. I'm inclined to agree that they are understaffed, probably overambitious, and as a result - overworked. Oh well.

edit
From limited personal experience (n=1) I can say that pushing fixes for obvious bugs is indeed not very hard and some maintainers seem to treat it as a nuisance and just want to be done with it. In particular, I was a bit :wtf: when somebody from the stable team just emailed me a question which releases the patch is compatible with, with little indication that my answer will receive any scrutiny.

So if you want to introduce a very stealthy vulnerability into Linux, come up with a commit which fixes some current problem while subtly breaking whatever -stable release is currently used by Ubuntu :P
ataradov:

--- Quote from: magic on April 24, 2021, 07:35:13 am ---Things clearly don't work well if anyone signed off on their shit patches. And those who did have just been caught with their pants down. It's the whole point of review to catch errors, intentional or not.

--- End quote ---
Code reviews are never 100% effective. Otherwise we would not have bugs in the software, since majority of big companies have code reviews.

Code reviews make sure that coding style is fine and the code is generally not complete garbage. Reviews would take forever if they had to review how specific patch affects the rest of the system.

I don't see why this is an issue that someone may intentionally introduce a hole. This sounds like a lot of work, it is much easier to find existing holes if you want them. There are plenty, for sure. And not only in the kernel, but in the rest of the user land too.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod