From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8BEC4CB4 for ; Sat, 8 Sep 2018 04:21:50 +0000 (UTC) Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F18888B for ; Sat, 8 Sep 2018 04:21:49 +0000 (UTC) Received: by mail-wr1-f48.google.com with SMTP id k5-v6so16694885wre.10 for ; Fri, 07 Sep 2018 21:21:49 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Andy Lutomirski Date: Fri, 7 Sep 2018 21:21:27 -0700 Message-ID: To: Jiri Kosina Content-Type: text/plain; charset="UTF-8" Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Sep 6, 2018 at 12:18 PM, Jiri Kosina wrote: > 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. > To a large extend, I think that the problems we had with Meltdown and Spectre weren't the fault of our processes so much as the fact that we weren't allowed to have a sane process. As far as I know, the number of upstream-focused non-Intel-employed Linux developers who were told about Meltdown and Spectre in a timely manner can be counted on a very small number of fingers on one hand. Those people had no channel to communicate with any of the distro people involved in a timely manner. This situation was not good. Perhaps the Linux community could have a small team that handles coordination of severe incidents along with a documented process for what happens when the process is invoked. It would need to be designed in such a way that vendors would be willing to use it when needed and that it gave the Linux world enough flexibility to actually handle the issue. At the very least, the relevant maintainers and perhaps some relevant upstream reviewers would get notified, and the people working on the issue for distros could actually communicate with the upstream folks. The total set of people involved would be small. It could be useful to try to get the process to work similarly to whatever Microsoft and Apple do. (There was another CVE that got much less press that I was involved, and it didn't get much attention in Linux land because Linux was only minimally affected. Despite being an Intel/AMD issue, all of the coordination was done by Microsoft, and it was done remarkably well once the process actually got started.)