[lkml]   [2009]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[PATCH] Update security bugs policy in Documentation/SecurityBugs
This patch updates the security bugs handling policy in
Documentation/SecurityBugs, to match with the current practices
and philosophy of the Linux kernel security team.

Please apply to avoid the masturbating monkeys in the security
circus from reporting misleading bugs with no security impact

Signed-off-by: Linus Turdvalds <>

--- tricky/Documentation/SecurityBugs
+++ honest/Documentation/SecurityBugs
@@ -1,7 +1,20 @@
Linux kernel developers take security very seriously. As such, we'd
like to know when a security bug is found so that it can be fixed and
-disclosed as quickly as possible. Please report security bugs to the
-Linux kernel security team.
+disclosed as quickly as possible.
+Unfortunately, since we do not believe in security bugs, your report
+could be classified as a reliability or performance problem. In such
+cases we will still fix the issue, but no specific disclosure will
+follow. Shall the reporter feel tempted to find references to said
+fix, he will require substantial amounts of time to walk through
+the commit logs in the affected git tree.
+Please report security bugs to the Linux kernel security team. We
+will provide the information to select members of the vendor-sec
+mailing list and Red Hat employees. The Linux kernel security team
+does not take any responsibility if said information is leaked or
+made available to third-parties through insecure communication

1) Contact

@@ -11,28 +24,46 @@ who will help verify the bug report and
It is possible that the security team will bring in extra help from
area maintainers to understand and fix the security vulnerability.

+The Linux kernel security team does not have a PGP public key at
+the moment, since information wants to be free.
As it is with any bug, the more information provided the easier it
will be to diagnose and fix. Please review the procedure outlined in
REPORTING-BUGS if you are unclear about what information is helpful.
Any exploit code is very helpful and will not be released without
consent from the reporter unless it has already been made public.
+Please do not send us binary-only exploit code, because we have no
+idea about how to unpack it.

2) 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
+to _not_ 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 solution is not well-tested, for vendor coordination or any other
+reason the team finds compelling, without any explanation required.
+However, we expect these delays to be short, measurable in days,
+not weeks or months. Please note that the vulnerability window might be
+measurable in years if the issue went unnoticed for such amounts of time.
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
+holds the final say when setting a disclosure date. Once you report a
+security bug to the team, you lose all rights to the process and who
+will manage or have access to the information. The timeframe for
disclosure is from immediate (esp. if it's already publically 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.
+disclosure date to be on the order of 30 days.

3) Non-disclosure agreements

The Linux kernel security team is not a formal body and therefore unable
to enter any non-disclosure agreements.
+4) Enforcement of these terms
+The Linux kernel security team can absolutely ignore the terms herein,
+without explanations required. This document does not provide legally
+enforceable terms by any means, nor necessarily expresses the practices
+and philosophy of the current security team.

 \ /
  Last update: 2009-06-01 20:43    [W:0.037 / U:2.696 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site