[Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues
Jiri Kosina
jikos at kernel.org
Thu Sep 6 19:18:07 UTC 2018
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
More information about the Ksummit-discuss
mailing list