Conversation

Replying to

So like, if there are legitimate commits, or a legitimate though occasionally incorrect static analysis effort, that get their commits targeted— well it doesn't matter if those commits are good or bad! The point is LKML *can't judge* if they're good or bad

Quote Tweet

Daniel Micay

@DanielMicay

Apr 22, 2021

Replying to @11rcombs @eevee and @mcclure111

They're removing a ton of useful fixes because they can't easily distinguish them from the tiny subset of the commits that were intentionally wrong. It's not accurate that they've easily identified which ones are bad. They're removing many useful fixes resulting in adding bugs.

Replying to

To the extent the Wu/Lu IEEESSP paper was a piece of legitimate blackhat security research, that is the *lesson* of the paper— that commits that are "hard to review" (large, obscure or claimed based on static analysis) can get in without LKML being able to judge their worth.

Replying to

So let's say Aditya Pakki submits a good-faith but nonsense static analysis commit, & Greg KH rejects it because Lu is (actually is) Aditya's advisor and accuses it of being bad faith. Well, sure, Greg KH should retract that statement, since it's probably legally actionable libel

Replying to

...But he probably also should reject the patch.

Replying to

and

It's only a big fuss because they made the Linux kernel look like an amateurish project. They're only making it worse with this response. It has no shortage of use-after-free bugs, including publicly disclosed ones. Most of the ones found by fuzzing get reported but not fixed.

Replying to

and

I watched a very interesting talk on exactly this the other day:

youtube.com

LPC2019 - Reflections on kernel quality, development process and...

In this talk Dmitry will highlight some of the areas for improvement related to release quality, security, and developer experience and productivity. Then tr...

Replying to

and

I think Greg KH is on the same page about this too. He's one of the kernel maintainers who acknowledges the scale of the problems and is very open and supportive of solutions. It *definitely* isn't the case for most of the core kernel maintainers though. It's not a consensus.

Replying to

and

It seems like LKML is at a disadvantage here because they inherently perform their public communications in the open. Trying to suss out what is happening and form a response during a security incident with the whole world watching sounds hellish. I'm sure I'd make mistakes.

Replying to

and

actual zero days and real dangerous incidents aren't handled via public email. Limiting who can view and interact with patches is a very very dangerous game that will always end in tears, I'm not working on open source so I can *maybe* be allowed to contribute or interact

Replying to

and

That's true in many cases where people choose to report it to their private mailing list. I wouldn't report security issues to their private list. I report issues privately to Google because they pay me, but I won't keep it private for 90+ days instead of fixing it for our users.

Replying to

Many people report security issues publicly. The vast majority of security issues are fixed without handling them as a security issue. In many cases, they know it is one, but they don't care about that aspect. There are far too many security fixes to deal with them all that way.

4:38 PM · Apr 22, 2021Twitter Web App

Replying to

It would be unreasonable to actually expect them to handle each security fix as a security fix and get a CVE assignment, etc. because there are far too many. A lot of them won't admit how bad things are and actively push back against attempts to make things better though...

Replying to

Greg KH is one of those people very often talking about how bad things are, laying out how horribly understaffed they are and how they need more resources, more testing, safer tooling, etc. He's very supportive of the effort to start adopting Rust drivers too.

Show replies