On Thu, Feb 15, 2024 at 05:10:50PM +0100, Oleksandr Natalenko wrote: > Hello. > > On čtvrtek 15. února 2024 13:04:56 CET Greg Kroah-Hartman wrote: > > On Wed, Feb 14, 2024 at 09:34:38AM +0100, Lukas Bulwahn wrote: > > > On Wed, Feb 14, 2024 at 9:01 AM Greg Kroah-Hartman > > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > The Linux kernel project now has the ability to assign CVEs to fixed > > > > issues, so document the process and how individual developers can get a > > > > CVE if one is not automatically assigned for their fixes. > > > > > > > > Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > > > Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx> > > > > Signed-off-by: Lee Jones <lee@xxxxxxxxxx> > > > > --- > > > > v3: fix up wording in security-bugs.rst based on the changes to the cve > > > > assignment process from v1, thanks to a private reviewer for > > > > pointing that out. > > > > v2: Grammer fixes based on review from Randy > > > > Updated paragraph about how CVE identifiers will be assigned > > > > (automatically when added to stable trees, or ask us for one > > > > directly before that happens if so desired) > > > > > > > > > > Hi Greg, Sasha, Lee, > > > > > > Generally, I think this is a great step forward on the whole "security > > > vulnerability mess" and this will certainly help me and others in the > > > embedded space to argue to update to recent stable kernel versions. > > > This can then finally put the practice of shipping multiple-year-old > > > kernel versions to an end. Often this was just done with the argument > > > that there is not a recent CVE and fix assigned to some recent stable > > > kernel version---and integrators think updates to recent kernel stable > > > versions are not needed and not recommended. > > > > > > I am looking forward to seeing what and how many stable commits are > > > going to get CVEs assigned. If Greg's policy from the Kernel Recipes > > > 2019 presentation comes into play, every git kernel hash (GKH)---at > > > least in the stable tree---could get a CVE identifier (just to be on > > > the safe side). But I assume you are going to use some expert > > > knowledge, heuristics or some machine-learning AI to make some commits > > > in the stable tree carrying a CVE identifier and some others not. > > > > Yes, that "expert knowledge" will be "review all patches by hand" just > > like we do today for all that are included in the stable trees. > > Not undermining your efforts in any way, but I'd like to get an honest answer: is this really true? For instance, > > $ git log --oneline v6.7.1..v6.7.2 | wc -l > 641 > > Is it physically possible to actually review all these backports in just five days? I did, yes. And have been doing so for 15+ years, practice makes it easier :) thanks, greg k-h
