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
|
Disclosure
|
||||||
----------
|
----------
|
||||||
|
|
||||||
The goal of the Linux kernel security team is to work with the
|
The goal of the Linux kernel security team is to work with the bug
|
||||||
bug submitter to bug resolution as well as disclosure. We prefer
|
submitter to understand and fix the bug. We prefer to publish the fix as
|
||||||
to fully disclose the bug as soon as possible. It is reasonable to
|
soon as possible, but try to avoid public discussion of the bug itself
|
||||||
delay disclosure when the bug or the fix is not yet fully understood,
|
and leave that to others.
|
||||||
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.
|
Publishing the fix may be delayed when the bug or the fix is not yet
|
||||||
A disclosure date is negotiated by the security team working with the
|
fully understood, the solution is not well-tested or for vendor
|
||||||
bug submitter as well as vendors. However, the kernel security team
|
coordination. However, we expect these delays to be short, measurable in
|
||||||
holds the final say when setting a disclosure date. The timeframe for
|
days, not weeks or months. A release date is negotiated by the security
|
||||||
disclosure is from immediate (esp. if it's already publicly known)
|
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
|
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
|
Coordination
|
||||||
------------
|
------------
|
||||||
|
|
Loading…
Reference in New Issue