Received-SPF: pass (google.com: domain of linux-kernel+bounces-66438-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Thu, 15 Feb 2024 09:43:46 +0100
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
Message-ID: <2024021521-bannister-unlaced-ba2b@gregkh>
References: <2024021430-blanching-spotter-c7c8@gregkh>
 <11248961-9180-4330-8537-1cd0037edb85@leemhuis.info>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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