On Mon, Apr 29, 2024 at 10:30:49AM +0200, Thorsten Leemhuis wrote:
On 29.04.24 09:51, Greg Kroah-Hartman wrote:
On Mon, Apr 29, 2024 at 09:18:29AM +0200, Thorsten Leemhuis wrote:
Document when to use of stable@kernel.org instead of stable@vger.kernel.org, as the two are easily mixed up and their difference not explained anywhere[1].
Link: https://lore.kernel.org/all/20240422231550.3cf5f723@sal.lan/ [1] Signed-off-by: Thorsten Leemhuis linux@leemhuis.info
Documentation/process/stable-kernel-rules.rst | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index b4af627154f1d8..ebf4152659f2d0 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -72,6 +72,10 @@ for stable trees, add this tag in the sign-off area:: Cc: stable@vger.kernel.org +Use ``Cc: stable@kernel.org`` instead when fixing unpublished vulnerabilities: +it reduces the chance of accidentally exposing the fix to the public by way of +'git send-email', as mails sent to that address are not delivered anywhere.
The "fun" part of just saying this is that then it is a huge "signal" to others that "hey, this might be a security fix!" when it lands in Linus's tree. But hey, we do what we can, I know my scripts always use this address just to put a bit more noise into that signal :)
Yeah, that's likely true. :-D
FWIW, we could stay more vague here and use a text like """Use ``Cc: stable@kernel.org`` instead when fixing something that should be kept private for the timing being: it will prevent the change for accidentally being exposed to the public through 'git send-email', as mails sent to that address are not delivered anywhere."""
The sign would not be that huge anymore, but I'm not sure if that makes any difference.
Yeah, let's leave this as-is for now.
That being said, it's good to have this documented now, thanks for it:
yw!
Reviewed-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
Many thx for your feedback to this and the other patches. Do you want to pick those up (last time I changes something in that text that was the case) or let Jonathan handle them?
Which ever Jonathan finds easier is fine for me.
thanks,
greg k-h