lkml.org 
[lkml]   [2024]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v3] Documentation: Document the Linux Kernel CVE process
From
On 14.02.24 09:00, Greg Kroah-Hartman 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.
> [...]

This following is just nitpicking, hence feel free to ignore.

> +As always, it is best to take all released kernel changes, as they are
> +tested together in a unified whole by many community members, and not as
> +individual cherry-picked changes. Also note that for many bugs, the
> +solution to the overall problem is not found in a single change, but by
> +the sum of many fixes on top of each other. Ideally CVEs will be
> +assigned to all fixes for all issues, but sometimes we do not notice
> +fixes in released kernels, so do not assume that because a specific
> +change does not have a CVE assigned to it, that it is not relevant to
> +take.

There are a four "not" in the last pretty long sentence which makes it
kinda hard to parse. Avoiding that could look like this:

Ideally CVEs will be assigned to all fixes for all issues -- but
sometimes we will fail to notice fixes, therefore assume that some
changes without an assigned CVE might still be relevant to take.

Or like this:

Ideally CVEs will be assigned to all fixes for all issues, but sometimes
we will overlook fixes -- therefore assume that some changes that lack
an assigned CVE might still be relevant to take.

Not sure if that really makes it better, I guess you as a native speaker
are a better judge here.

Ciao, Thorsten (who also wondered what "to all fixes for all issues"
exactly means, but whatever)


\
 
 \ /
  Last update: 2024-05-27 15:04    [W:0.242 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site