From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Thorsten Leemhuis <linux@leemhuis.info>
Cc: corbet@lwn.net, workflows@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
security@kernel.org, Kees Cook <keescook@chromium.org>,
Sasha Levin <sashal@kernel.org>, Lee Jones <lee@kernel.org>
Subject: Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process
Date: Thu, 15 Feb 2024 09:43:46 +0100 [thread overview]
Message-ID: <2024021521-bannister-unlaced-ba2b@gregkh> (raw)
In-Reply-To: <11248961-9180-4330-8537-1cd0037edb85@leemhuis.info>
On Thu, Feb 15, 2024 at 09:17:59AM +0100, Thorsten Leemhuis wrote:
> 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.
I like the wording change here, thanks, I'll take it for the next
revision. It is ackward as I wrote it and your update makes it simpler
and more obvious.
> Ciao, Thorsten (who also wondered what "to all fixes for all issues"
> exactly means, but whatever)
Meaning "we will miss things" so don't assume that because we don't call
it out here, it's not important to take. Yeah, again, ackward wording,
language is "fun"...
thanks for the review!
greg k-h
next prev parent reply other threads:[~2024-02-15 8:43 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-14 8:00 Greg Kroah-Hartman
2024-02-14 8:34 ` Lukas Bulwahn
2024-02-15 12:04 ` Greg Kroah-Hartman
2024-02-15 16:10 ` Oleksandr Natalenko
2024-02-15 17:49 ` Greg Kroah-Hartman
2024-02-14 8:37 ` Vegard Nossum
2024-02-15 11:50 ` Greg Kroah-Hartman
2024-02-15 12:24 ` Vegard Nossum
2024-02-16 8:28 ` Jani Nikula
2024-02-16 11:22 ` Greg Kroah-Hartman
2024-02-16 14:58 ` Jonathan Corbet
2024-02-17 11:56 ` Greg Kroah-Hartman
2024-02-14 13:10 ` Krzysztof Kozlowski
2024-02-15 12:00 ` Greg Kroah-Hartman
2024-02-14 13:41 ` Konstantin Ryabitsev
2024-02-15 11:59 ` Greg Kroah-Hartman
2024-02-14 13:43 ` Jiri Kosina
2024-02-14 13:55 ` Mark Brown
2024-02-14 14:32 ` Greg Kroah-Hartman
2024-02-14 14:46 ` Jiri Kosina
2024-02-14 15:10 ` Mark Brown
2024-02-14 13:58 ` Greg Kroah-Hartman
2024-02-14 14:38 ` Jiri Kosina
2024-02-14 15:09 ` Greg Kroah-Hartman
2024-02-15 8:17 ` Thorsten Leemhuis
2024-02-15 8:43 ` Greg Kroah-Hartman [this message]
2024-02-15 17:54 ` Michal Hocko
2024-02-15 18:20 ` Greg Kroah-Hartman
2024-02-15 18:36 ` Michal Hocko
2024-02-16 11:25 ` Greg Kroah-Hartman
2024-02-16 13:20 ` Michal Hocko
2024-02-16 15:34 ` Greg Kroah-Hartman
2024-02-16 16:51 ` Michal Hocko
2024-02-15 19:40 ` Kees Cook
2024-02-16 7:41 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2024021521-bannister-unlaced-ba2b@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=corbet@lwn.net \
--cc=keescook@chromium.org \
--cc=lee@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@leemhuis.info \
--cc=sashal@kernel.org \
--cc=security@kernel.org \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox