Received: by 10.223.185.116 with SMTP id b49csp5549135wrg; Wed, 7 Mar 2018 13:48:43 -0800 (PST) X-Google-Smtp-Source: AG47ELvwjR5QHjZsQh98h+1jj5Ymw+i89zVqXhow1iG8+1pNT9ZoWGC1ZuoipyKH6YcClAFuIgkt X-Received: by 10.99.163.111 with SMTP id v47mr19044489pgn.80.1520459323511; Wed, 07 Mar 2018 13:48:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520459323; cv=none; d=google.com; s=arc-20160816; b=pNAf7a59hEW95LPcTq9wjpfhIoIys7K4sfHrenqbTPX16dc39Jdt2X4qPvgpjbdM/Q sTNaJH/KqwBaJerThududSf8ZKCcDf4lmPMR4R9padLbqOqzh7CSYabPkc3uDzvs3MqB tqlC6IsyEPQZ2wzmHMsxam2gGuE47B5gs3yH62kufyZ8P+TeTgAf9AUJbKkyQJYSYaBd ezlNN3rwoa8lJQOFaUH7XsDhqpHDIN04826FDB3g6MpQgQPfbbL9OTwPX+j7lGwu5wn2 8GTSMkifSBUjXRCuAaiS8XAxvlRcCU2efZTd2h6WBNqLi1hW8doIQKD797zoLvUPZpqU RmjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:from:cc:to:subject :arc-authentication-results; bh=F+s1BygsLe5aB8bE5FQ8Z6NQhwz0df59Qt3L2ixFawg=; b=i1ua/HHKBMXmYvpbmFt748Bd5dkBKF6wXNNr/3KisvRDBCQncyeU8twSsrDGL9SUQF xUu1N31pTgORdV1XsPWxtc1KhsfCH4NqHHSzViw1BqBCO/RMuvuKUaE+gQP/qXYxfVoi BKgL0A2X01e0TO6GmBt1knwfXdqQFy/lTskUOCgTcKlNrffljPM8MhIzWS33BCf33Xje tYJbdxd5NmVArdofuddJ7hMccIZ/Ptwo+jisxKSC1+uY6SCKRzmJyxo3N95ynPz2BP6f lyi0xUBDxB4Mf/3pOo93/M3tifnhDIEE4zjzxUnaXRn3Z6JKjS/Fwrm7NojouYup/o4n CO1w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a1si9462177pfc.147.2018.03.07.13.48.28; Wed, 07 Mar 2018 13:48:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933554AbeCGVrZ (ORCPT + 99 others); Wed, 7 Mar 2018 16:47:25 -0500 Received: from mga03.intel.com ([134.134.136.65]:37808 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754458AbeCGVrX (ORCPT ); Wed, 7 Mar 2018 16:47:23 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2018 13:47:23 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,437,1515484800"; d="scan'208";a="22841928" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.39.119]) by orsmga007.jf.intel.com with ESMTP; 07 Mar 2018 13:47:23 -0800 Subject: [PATCH] [v2] docs: clarify security-bugs disclosure policy To: linux-kernel@vger.kernel.org Cc: Dave Hansen , dan.j.williams@intel.com, tglx@linutronix.de, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, gnomes@lxorguk.ukuu.org.uk, aarcange@redhat.com, luto@kernel.org, keescook@google.com, tim.c.chen@linux.intel.com, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, linux-doc@vger.kernel.org, corbet@lwn.net, mark.rutland@arm.com From: Dave Hansen Date: Wed, 07 Mar 2018 13:46:24 -0800 Message-Id: <20180307214624.D4361772@viggo.jf.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Dave Hansen I think we need to soften the language a bit. It might scare folks off, especially the: We prefer to fully disclose the bug as soon as possible. which is not really the case. Linus says: It's not full disclosure, it's not coordinated disclosure, and it's not "no disclosure". It's more like just "timely open fixes". I changed a bit of the wording in here, but mostly to remove the word "disclosure" since it seems to mean very specific things to people that we do not mean here. Signed-off-by: Dave Hansen Reviewed-by: Dan Williams Cc: Thomas Gleixner Cc: Greg Kroah-Hartman Cc: Linus Torvalds Cc: Alan Cox Cc: Andrea Arcangeli Cc: Andy Lutomirski Cc: Kees Cook Cc: Tim Chen Cc: Alexander Viro Cc: Andrew Morton Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet Cc: Mark Rutland --- b/Documentation/admin-guide/security-bugs.rst | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff -puN Documentation/admin-guide/security-bugs.rst~embargo2 Documentation/admin-guide/security-bugs.rst --- a/Documentation/admin-guide/security-bugs.rst~embargo2 2018-03-07 13:23:49.390228208 -0800 +++ b/Documentation/admin-guide/security-bugs.rst 2018-03-07 13:42:37.618225395 -0800 @@ -29,18 +29,20 @@ made public. Disclosure ---------- -The goal of the Linux kernel security team is to work with the -bug submitter to bug resolution as well as disclosure. We prefer -to fully disclose the bug as soon as possible. It is reasonable to -delay disclosure when the bug or the fix is not yet fully understood, -the solution is not well-tested or for vendor coordination. However, we -expect these delays to be short, measurable in days, not weeks or months. -A disclosure date is negotiated by the security team working with the -bug submitter as well as vendors. However, the kernel security team -holds the final say when setting a disclosure date. The timeframe for -disclosure is from immediate (esp. if it's already publicly known) +The goal of the Linux kernel security team is to work with the bug +submitter to understand and fix the bug. We prefer to publish the fix as +soon as possible, but try to avoid public discussion of the bug itself +and leave that to others. + +Publishing the fix may be delayed when the bug or the fix is not yet +fully understood, the solution is not well-tested or for vendor +coordination. However, we expect these delays to be short, measurable in +days, not weeks or months. A release date is negotiated by the security +team working with the bug submitter as well as vendors. However, the +kernel security team holds the final say when setting a timeframe. The +timeframe varies from immediate (esp. if it's already publicly known bug) to a few weeks. As a basic default policy, we expect report date to -disclosure date to be on the order of 7 days. +release date to be on the order of 7 days. Coordination ------------ _