|author||Dave Hansen <email@example.com>||2018-03-07 13:46:24 -0800|
|committer||Jonathan Corbet <firstname.lastname@example.org>||2018-03-09 10:42:06 -0700|
docs: clarify security-bugs disclosure policy
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 <email@example.com> Reviewed-by: Dan Williams <firstname.lastname@example.org> Reviewed-by: Greg Kroah-Hartman <email@example.com> Acked-by: Kees Cook <firstname.lastname@example.org> Cc: Thomas Gleixner <email@example.com> Cc: Linus Torvalds <firstname.lastname@example.org> Cc: Alan Cox <email@example.com> Cc: Andrea Arcangeli <firstname.lastname@example.org> Cc: Andy Lutomirski <email@example.com> Cc: Tim Chen <firstname.lastname@example.org> Cc: Alexander Viro <email@example.com> Cc: Andrew Morton <firstname.lastname@example.org> Cc: Mark Rutland <email@example.com> Signed-off-by: Jonathan Corbet <firstname.lastname@example.org>
1 files changed, 13 insertions, 11 deletions
diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
index 47574b382d75..30491d91e93d 100644
@@ -29,18 +29,20 @@ made public.
-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.