From: Jiri Kosina <jkosina@suse.cz>
To: ksummit@lists.linux.dev
Subject: [MAINTAINERS SUMMIT] Handling of embargoed security issues -- security@korg vs. linux-distros@
Date: Tue, 15 Aug 2023 11:28:44 +0200 (CEST) [thread overview]
Message-ID: <nycvar.YFH.7.76.2308150927190.14207@cbobk.fhfr.pm> (raw)
Hi,
I believe that reporters of embargoed security issues have always been
confused about reporting to security@kernel.org vs. reporting to
linux-distros@, as those two lists have completely different ways of
dealing with the report (different purpose, different deadlines, different
obligations imposed on the reporters, etc).
Our documentation originally suggested reporting to both in some "hybrid"
mode, and the results were not great, quite often leading to confusion
left and right.
This led to a slight update to our documentation [1], where reporters are
discouraged from reporting kernel issues to linux-distros@ ever.
While I generally agree with the change *now*, given the current
conditions, I would like to bring this up for discussion on how to deal
with this longer term.
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.
If this process doesn't happen, many kernel security (with CVE potentially
eventually assigned retroactively) fixes will go by unnoticed, as distro
kernel people will never be explicitly made aware of them, and distros
will be missing many of the patches. Which I don't think is a desired end
effect.
I have been discussing this with Greg already some time ago, and I know
that his response to this is "then use -stable, and you'll get everything
automatically" (which is obviously true, because stable is represented at
security@kernel.org), but:
- Neither us (nor RedHat, nor Ubuntu, as far as I am aware) are picking
stable as a primary base for distro kernels. There are many reasons for
this (lifecycles not matching, stable picking up way too many things for
taste of some of us, etc), but that's probably slightly off-topic for
this discussion
- For several varying reasons, our security people really struggle with
ensuring that whenever CVE is published, we as a distro can guarantee,
that fix for that particular CVE is included. linux-distros@ provides
that connection between bugfix and CVE report, and that is lost if the
fix goes only through security@kernel.org
And yes, I hate the whole CVE thing with passion, but it unfortunately
exists and is seen as an industry standard by many. And with us not
being able to systematically / automatically guarantee that fix for
particulart CVE is included, Linux will be not allowed into many places.
I am currently not sure what exactly would be the solution to this.
One thing to try would of course be to discuss with linux-distros@ people
whether they'd be willing to adjust their rules to fit our needs better;
but before that happens, we should be ourselves clear on what our needs
towards them actually are.
Another option might be to ensure representation of distros at
security@kernel.org, but that would completely change the purpose of it,
and I don't think that's desired.
... ?
[1] https://git.kernel.org/linus/4fee0915e649b
Thanks,
--
Jiri Kosina
Director, SUSE Labs Core
next reply other threads:[~2023-08-15 9:28 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-15 9:28 Jiri Kosina [this message]
2023-08-15 10:17 ` [MAINTAINERS SUMMIT] Handling of embargoed security issues -- security@korg vs. linux-distros@ Vegard Nossum
2023-08-15 10:34 ` Jiri Kosina
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.2308150927190.14207@cbobk.fhfr.pm \
--to=jkosina@suse.cz \
--cc=ksummit@lists.linux.dev \
/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).