On Wed, Mar 7, 2018 at 1:46 PM, Dave Hansen <dave.han...@linux.intel.com> wrote: > > From: Dave Hansen <dave.han...@linux.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. 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.han...@linux.intel.com> > Reviewed-by: Dan Williams <dan.j.willi...@intel.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> > Cc: Linus Torvalds <torva...@linux-foundation.org> > Cc: Alan Cox <gno...@lxorguk.ukuu.org.uk> > Cc: Andrea Arcangeli <aarca...@redhat.com> > Cc: Andy Lutomirski <l...@kernel.org> > Cc: Kees Cook <keesc...@google.com> > Cc: Tim Chen <tim.c.c...@linux.intel.com> > Cc: Alexander Viro <v...@zeniv.linux.org.uk> > Cc: Andrew Morton <a...@linux-foundation.org> > Cc: linux-doc@vger.kernel.org > Cc: Jonathan Corbet <cor...@lwn.net> > Cc: Mark Rutland <mark.rutl...@arm.com> > --- > > b/Documentation/admin-guide/security-bugs.rst | 24 +++++++++++++----------- > 1 file changed, 13 insertions(+), 11 deletions(-) > > diff -puN Documentation/admin-guide/security-bugs.rst~embargo2 > Documentation/admin-guide/security-bugs.rst > --- a/Documentation/admin-guide/security-bugs.rst~embargo2 2018-03-07 > 13:23:49.390228208 -0800 > +++ b/Documentation/admin-guide/security-bugs.rst 2018-03-07 > 13:42:37.618225395 -0800 > @@ -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)
Nit: I think "a" is missing. I was expecting: "... already a 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. > +release date to be on the order of 7 days. Otherwise, yeah, looks good. Acked-by: Kees Cook <keesc...@chromium.org> -Kees -- Kees Cook Pixel Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
