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 <dave.hansen@linux.intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Kees Cook <keescook@chromium.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
parent
6234c7bd8c
commit
7f5d465f4d
|
@ -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
|
||||
------------
|
||||
|
|
Loading…
Reference in a new issue