alexanderkjall

Today I have spent way too much time handling the https://copy.fail situation #copyfail The persons who discovered it didn't notify the distribution security list, so no patched kernels was available for people to install when they released it. But they did have time to write an exploit, and thought it was a good idea to distribute that on day one, before vendors had time to provide patches. I'm not very impressed with xint.io, I guess it's the marketing department that runs the show.

@fedops @penguin42 I'm not part of any distro security team, so I can't really speak for any of them. But Debian contains about 40000 source packages as of may 2026, it feels slightly unrealistic that the security team are supposed to track patches for all of those and understand which ones contain important security fixes. If you find a vulnerability, register a website and build an exploit, then notifying the vendors beforehand feels like a quite small thing in comparison.

@penguin42 It did not, the process is somewhat described here: https://docs.kernel.org/process/security-bugs.html

@asltf Since the kernel have the policy "every bug gets a CVE" ( https://docs.kernel.org/process/cve.html ), that seems like a full time job for multiple people. They published 200 CVE's since 2026-04-24: https://lore.kernel.org/linux-cve-announce/topics_new.html I guess the security team of your favorite linux distribution would appreciate some support.

@LabanSkoller @jmm They do not, the process is somewhat described here: https://docs.kernel.org/process/security-bugs.html

@raven667 @OmegaPolice I agree that it would be great if the kernel security team had a process that made life simpler for downstream vendors. But since neither me or my employer contributes anything to make that happen I don't think it's my place to have public opinions about it. Personally I would love to see more effort focused on reducing the attack surface of the kernel.