Re: [MAINTAINERS SUMMIT] Handling of embargoed security issues -- security@korg vs. linux-distros@

[Jiri Kosina <jikos@kernel.org>]

On Tue, 15 Aug 2023, Daniel Borkmann wrote:

> Not really answering your question, but the above is also a somewhat 
> misleading "assurance" for distros. Some security fixes might 
> potentially have come in via AUTOSEL, and some others might not have 
> been discussed at security@k.o in the first place. How would you 
> classify which ones of the whole set are relevant for distros and which 
> ones are not?
> 
> Imho, if distros decide to maintain their own trees outside of stable it 
> would still require manual triaging of the set of stable patches that 
> went into a minor release (and if in doubt, just cherry-pick the patch) 
> - that's just the cost to pay for maintaining non-stable base. It's the 
> same issue as discussed in [0].
> 
>   [0]
> https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/

Whith my kernel developer hat on, I fully agree. The whole CVE handling 
has been a disaster for many reasons, and it's sad that people still 
believe in it. Fixes are fixes, and you ideally want them all, right?

With my distro kernel person hat on, the linux-distros@ process helps us a 
lot with a first iteration of identifying the big set of things that we 
(well, our security team) should take a look into immediately, because 
they have been explicitly reported (and verified) to be security relevant.

It has been the case with pretty much every opensource/Linux-relevant 
project out there. Kernel has now removed itself from it. Again, from very 
good and understandable reasons for now, but I don't think that should 
mark the ultimate end of the story.

That doesn't mean that we don't have a process for evaluating what to 
merge/cherry-pick from other trees (including stable, of course). We 
absolutely do. We just can't relistically base on -stable, for multitude 
of reasons.

Thanks,

-- 
Jiri Kosina
SUSE Labs