From: Jiri Kosina <jikos@kernel.org>
To: Vegard Nossum <vegard.nossum@oracle.com>
Cc: ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] Handling of embargoed security issues -- security@korg vs. linux-distros@
Date: Tue, 15 Aug 2023 12:34:49 +0200 (CEST) [thread overview]
Message-ID: <nycvar.YFH.7.76.2308151226010.14207@cbobk.fhfr.pm> (raw)
In-Reply-To: <658e739b-c164-c360-d6a3-eb4fb15ae02e@oracle.com>
On Tue, 15 Aug 2023, Vegard Nossum wrote:
> I think it's worth pointing out that the latest update to the
> documentation (where reporters are discouraged from reporting kernel
> issues to linux-distros@ ever) came just after a private discussion (on
> both mailing lists) about the StackRot/CVE-2023-3269 vulnerability where
> Linus in particular came out hard against the linux-distros policy, in
> particular the requirement to disclose PoCs if those were shared with
> the list in the first place. I therefore think that Linus himself needs
> to be involved in this discussion and that his arguments need to be made
> in public instead of just paraphrased by me.
And I acutally agree with Linus there -- I see no huge value with POCs
being shared there.
I know the linux-distros@ people would probably argue that POCs are
required so that they can integrate them into their QA / CI / regression
testing pipeline, but, quite honestly, I don't believe this is happening
in reality anyway.
> > With my distro hat on, I really want the kernel security bugs to be
> > *eventually* processed through linux-distros@ somehow, for one sole
> > reason: it means that our distro security people will be aware of it,
> > track it internally, and keep an eye on the fix being ported to all of our
> > codestreams. This is exactly how this is done for all other packages.
> >
> > I would be curious to hear about this from other distros, but I sort of
> > expect that they would agree.
>
> +1 from me; the distros list has been an extremely important resource
> for distros in order to get fixes shipped out with minimal delay.
>
> I keep saying this as well: almost all users get their kernels through
> distros. Very few end users build their own kernels from source; in
> other words, it's not enough that a fix has been committed to
> mainline/stable git to consider it fixed. The connection between
> upstream git and end users is clearly the distros, so distros should be
> in the loop _at some point_.
Thanks for underlying exactly my point here.
> I'll throw in another idea: distros@kernel.org.
>
> A closed list which will be notified by security@kernel.org once they
> feel patches for a particular issue are ready for testing/consumption by
> distros (and hopefully before the issue is disclosed publicly, if the
> reporter still wishes to do that).
>
> The members and list rules would be totally up to the security team to
> decide.
That might be a viable option as well. It'll be a little bit inconvenient
for the distro security people to follow different sets of rules, but
still better than current situation. They'll probably also want the
"assign a CVE" process that currently works on linux-distros@, but that's
doable. I can ask SUSE security people what they'd think about such an
idea, input from others would also be welcome.
(and maybe, if the distros@ process really gets established,
linux-distros@ will finally realize that they'd better adjust their
process to accomodate kernel :) ).
Thanks,
--
Jiri Kosina
SUSE Labs
next prev parent reply other threads:[~2023-08-15 10:34 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-15 9:28 [MAINTAINERS SUMMIT] Handling of embargoed security issues -- security@korg vs. linux-distros@ Jiri Kosina
2023-08-15 10:17 ` Vegard Nossum
2023-08-15 10:34 ` Jiri Kosina [this message]
2023-08-15 11:23 ` Greg KH
2023-08-15 12:42 ` Steven Rostedt
2023-08-15 13:17 ` Daniel Borkmann
2023-08-15 14:19 ` Laurent Pinchart
2023-08-15 22:04 ` Jiri Kosina
2023-08-15 14:20 ` Catalin Marinas
2023-08-15 14:41 ` Greg KH
2023-08-15 15:04 ` Steven Rostedt
2023-08-15 15:51 ` Greg KH
2023-08-15 15:08 ` Greg KH
2023-08-15 18:46 ` Konrad Rzeszutek Wilk
2023-08-15 19:41 ` Greg KH
2023-08-15 22:13 ` Jiri Kosina
2023-08-15 22:31 ` Steven Rostedt
2023-08-16 14:55 ` Greg KH
2024-02-16 17:14 ` Michal Suchánek
2024-02-16 17:34 ` Greg KH
2024-02-16 18:13 ` Michal Suchánek
2024-02-16 18:16 ` Jiri Kosina
2023-08-15 22:17 ` Jiri Kosina
2023-08-16 14:57 ` Greg KH
2023-08-16 17:22 ` Jiri Kosina
2023-08-16 18:38 ` Vegard Nossum
2023-08-16 15:26 ` Solar Designer
2023-08-25 11:17 ` Donald Buczek
2023-08-29 8:46 ` Miroslav Benes
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=nycvar.YFH.7.76.2308151226010.14207@cbobk.fhfr.pm \
--to=jikos@kernel.org \
--cc=ksummit@lists.linux.dev \
--cc=vegard.nossum@oracle.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).