Hacker News Reader

Comment by Sir_Cmpwn | Hacker News Reader

Thanks for clarifying, Greg.

>It usually does this by just dragging in the responsible parties, but many times it just fixes the problems themselves and submits the patches to the proper part of the kernel.

I think this is the key - once the patches are submitted they go through the normal workflow and aren't any different from a typical patch, right?

View on HN

Yes, once the patches are generated, they get submitted just like any other kernel change, sent to the responsible subsystem and maintainer for inclusion like any other kernel change.

I think this is where the problems becomes apparent. The change then has to go through the subsystem's patch flow (in public) then into the merge window (in public) and sit in the release pipeline (in public) until the window closes and all of the rc's are through.

Personally I don't think this is a huge deal, but it's where the disconnect between the security person's ideal worldview and the reality of how Linux is built colllide.

Distros could speed this up. If the security team notifies RedHat, Ubuntu, etc and they can apply the patch for their kernels immediately. They probably need to backport it anyways, because no distro (well, maybe Arch?) just uses the latest Linux release.

FWIW, during the last year Fedora frequently had newer kernels than arch.

It seems to be a huge deal if it leads to the kernel folks both breaking the embargo and getting patches out later than they could have.

Only if you think either of those things are a huge deal either, which I don't.

Breaking embargoes generally leads to easy, packaged exploits appearing that many days earlier than they otherwise would have. Obviously patches being delayed gets you on the other end. How are either of those not a huge deal? Do you just think it's not important to have patched systems against published vulnerabilities?

Reply on news.ycombinator.com