lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180306233140.268BD8E1@viggo.jf.intel.com>
Date:   Tue, 06 Mar 2018 15:31:40 -0800
From:   Dave Hansen <dave.hansen@...ux.intel.com>
To:     linux-kernel@...r.kernel.org
Cc:     Dave Hansen <dave.hansen@...ux.intel.com>, tglx@...utronix.de,
        gregkh@...uxfoundation.org, torvalds@...ux-foundation.org,
        gnomes@...rguk.ukuu.org.uk, aarcange@...hat.com, luto@...nel.org,
        keescook@...gle.com, tim.c.chen@...ux.intel.com,
        dan.j.williams@...el.com, viro@...iv.linux.org.uk,
        akpm@...ux-foundation.org, linux-doc@...r.kernel.org,
        corbet@....net, mark.rutland@....com
Subject: [PATCH] docs: clarify security-bugs disclosure policy


From: Dave Hansen <dave.hansen@...ux.intel.com>

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.  As Greg mentioned in private mail, we
really do not prefer to disclose things until *after* a fix.  The
whole "we have the final say" is also a bit harsh.

Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc: Andrea Arcangeli <aarcange@...hat.com>
Cc: Andy Lutomirski <luto@...nel.org>
Cc: Kees Cook <keescook@...gle.com>
Cc: Tim Chen <tim.c.chen@...ux.intel.com>
Cc: Dan Williams <dan.j.williams@...el.com>
Cc: Alexander Viro <viro@...iv.linux.org.uk>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-doc@...r.kernel.org
Cc: Jonathan Corbet <corbet@....net>
Cc: Mark Rutland <mark.rutland@....com>
---

 b/Documentation/admin-guide/security-bugs.rst |   26 +++++++++++++++-----------
 1 file changed, 15 insertions(+), 11 deletions(-)

diff -puN Documentation/admin-guide/security-bugs.rst~embargo Documentation/admin-guide/security-bugs.rst
--- a/Documentation/admin-guide/security-bugs.rst~embargo	2018-03-06 14:47:04.519431230 -0800
+++ b/Documentation/admin-guide/security-bugs.rst	2018-03-06 14:57:46.410429629 -0800
@@ -29,18 +29,22 @@ 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.
+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 after a fix is available.  It is
+customary 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 typically 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)
-to a few weeks.  As a basic default policy, we expect report date to
-disclosure date to be on the order of 7 days.
+bug submitter as well as affected vendors.  The security team prefers
+coordinated disclosure and will consider pre-existing, reasonable
+disclosure dates.
+
+The timeframe for disclosure ranges from immediate (esp. if it's
+already publicly known) to a few weeks.  As a basic default policy, we
+expect report date to disclosure date to be on the order of 7 days.
 
 Coordination
 ------------
_

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ