From: Jiri Kosina <jikos@kernel.org>
To: ksummit-discuss@lists.linuxfoundation.org
Subject: [Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues
Date: Thu, 6 Sep 2018 21:18:07 +0200 (CEST) [thread overview]
Message-ID: <nycvar.YFH.7.76.1809062054450.15880@cbobk.fhfr.pm> (raw)
I believe we have reasonably well-established process for handling
security issues that are a matter of a single, reasonably self-contained
fixup.
Past experiences with Meltdown, Spectre and L1TF have shown that we're not
really ready to handle that in a reasonably sane way yet.
Yeah, at the end of the day we managed to have the fixes propagated in
time to Linus' tree, to stable, and to distros as well, but it was
completely out of anything regular, and definitely had permanent damaging
effects (I'd say both in personal and business aspects for almost
everybody who had to participate).
I'd believe that everybody involved would agree that this didn't work
really well, and if it potentially would have to happen again (and we
already went through it at least twice this year), it would not be
sustainable.
I am not completely sure what we could do to improve this, especially with
our kernel community hats on -- I am pretty sure a lot is happening on the
corporate level between individual "corporate stakeholders". Ideas I think
would be worth discussing:
- how to adapt our processess to be able to deal with such situations
better should they happen in the future again. So far all our
longer-term development has been concentrated around LKML (and other
MLs) and the existing maintainership communities / structures, but the
embargos for new big features don't really fit into this
- how to make sure that proper pressure is applied on the companies that
are handling embargoes irresponsibly wrt. linux/opensource development
(well, even some proprietary vendors were rather unhappy with those
events) from us as the linux kernel community
+ and perhaps even more importantly, what exactly we should be pressing
for
Thanks,
--
Jiri Kosina
SUSE Labs
next reply other threads:[~2018-09-06 19:18 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-06 19:18 Jiri Kosina [this message]
2018-09-06 20:56 ` [Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues Linus Torvalds
2018-09-06 21:14 ` Jiri Kosina
2018-09-06 22:51 ` Eduardo Valentin
2018-09-07 9:17 ` Jani Nikula
2018-09-07 14:43 ` David Woodhouse
2018-09-06 22:55 ` Eduardo Valentin
2018-09-07 8:21 ` Geert Uytterhoeven
2018-09-10 23:26 ` Eduardo Valentin
2018-09-11 8:45 ` Greg KH
2018-09-11 17:10 ` Dave Hansen
2018-09-11 18:28 ` Greg KH
2018-09-11 18:44 ` Thomas Gleixner
2018-09-07 13:30 ` Jiri Kosina
2018-09-09 12:55 ` Greg KH
2018-09-09 19:48 ` Jiri Kosina
2018-09-10 4:04 ` Eduardo Valentin
2018-09-12 7:03 ` Greg KH
2018-09-10 4:12 ` Eduardo Valentin
2018-09-10 11:10 ` Mark Brown
2018-09-12 4:22 ` Balbir Singh
2018-09-08 4:21 ` Andy Lutomirski
2018-09-08 8:56 ` Thomas Gleixner
2018-09-08 11:21 ` Mauro Carvalho Chehab
2018-09-08 11:34 ` Greg KH
2018-09-08 14:20 ` Andy Lutomirski
2018-09-08 15:29 ` Greg KH
2018-09-08 15:00 ` James Bottomley
2018-09-08 15:32 ` Greg KH
2018-09-08 15:54 ` James Bottomley
2018-09-08 19:49 ` Linus Torvalds
2018-09-08 21:24 ` James Bottomley
2018-09-08 22:33 ` Andy Lutomirski
2018-09-09 12:18 ` Mauro Carvalho Chehab
2018-09-10 22:59 ` Dave Hansen
2018-09-11 8:48 ` Greg KH
2018-09-09 12:51 ` Greg KH
2018-09-09 14:20 ` Linus Torvalds
2018-09-09 14:38 ` James Bottomley
2018-09-09 14:51 ` Andy Lutomirski
2018-09-09 17:20 ` Theodore Y. Ts'o
2018-09-09 17:48 ` David Woodhouse
2018-09-09 18:17 ` Andy Lutomirski
2018-09-09 18:56 ` Theodore Y. Ts'o
2018-09-09 19:19 ` Andy Lutomirski
2018-09-09 20:20 ` Jiri Kosina
2018-09-09 21:36 ` James Bottomley
2018-09-10 9:25 ` Thomas Gleixner
2018-09-10 14:40 ` James Bottomley
2018-09-11 8:20 ` Jiri Kosina
2018-09-11 9:03 ` Thomas Gleixner
2018-09-09 19:41 ` Jiri Kosina
2018-09-08 19:26 ` Jiri Kosina
2018-09-08 19:47 ` James Bottomley
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.1809062054450.15880@cbobk.fhfr.pm \
--to=jikos@kernel.org \
--cc=ksummit-discuss@lists.linuxfoundation.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).