Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy
On Sun, Apr 22, 2018 at 3:00 AM, Pavel Machek wrote: > > On Fri 2018-03-09 13:15:31, Linus Torvalds wrote: >> >> Oh, I don't want to be taken seriously by people who use gpg >> encrypted email. > > Heh. I see that gpg has some usability problems, but we do encrypt our > http connections, and email is at least as sensitive. It's not about sensitivity. It's about the technology actually *working*. PGP does not work for email. Never has, never will. It's unusable crap. Nobody sane uses it, because the cost is just too damn high. Make it as easy to use as https, and things will change. As it is, don't even bother. Thomas helped me get S/MIME working, and even for that I had to fix an alpine bug that caused alpine to SIGSEGV. And that's _convenient_ compared to pgp email. Whee. Linus -- 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
Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy
Hi! On Fri 2018-03-09 13:15:31, Linus Torvalds wrote: > On Fri, Mar 9, 2018 at 12:45 PM, Alan Cox wrote: > > > > If you want to be taken seriously then I think minimum you also need to > > - Give a GPG key for messages to the list > > Oh, I don't want to be taken seriously by people who use gpg > encrypted email. Heh. I see that gpg has some usability problems, but we do encrypt our http connections, and email is at least as sensitive. > > - State what security is in place (encryption etc) to protect the list > > itself > > That could be stated, but it's worth noting the other rules. > > If you have some long corrupt vendor disclosure period and are worried > about any good guys finding out (the bad guys probably already have > it), we're not the list for you anyway. > > Keep your "we'll keep security problems under wraps so that they can > be exploited for a long time" emails to yourself, or send them to > /dev/null. Umm, they will not sent it to /dev/null, as that is not encrypted :-). I guess I can act as this kind of /dev/null. It might be useful to note the issues, and for the serious ones notify you few days before the "long" embargo is going to expire... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy
On Fri, Mar 9, 2018 at 12:45 PM, Alan Cox wrote: > > If you want to be taken seriously then I think minimum you also need to > - Give a GPG key for messages to the list Oh, I don't want to be taken seriously by people who use gpg encrypted email. It's garbage and should be shunned as such. I keep quoting this: https://motherboard.vice.com/en_us/article/vvbw9a/even-the-inventor-of-pgp-doesnt-use-pgp and anybody who thinks pgp encrypted email is fine is a clown. > - State what security is in place (encryption etc) to protect the list > itself That could be stated, but it's worth noting the other rules. If you have some long corrupt vendor disclosure period and are worried about any good guys finding out (the bad guys probably already have it), we're not the list for you anyway. Keep your "we'll keep security problems under wraps so that they can be exploited for a long time" emails to yourself, or send them to /dev/null. Linus -- 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
Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy
On Wed, 07 Mar 2018 13:46:24 -0800 Dave Hansen wrote: > From: Dave Hansen > > 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. > If you want to be taken seriously then I think minimum you also need to - Give a GPG key for messages to the list - State what security is in place (encryption etc) to protect the list itself There are probably a lot more things people would ask but given the policy now clear that it's basically just an 'early tip off'/'make sure Linus doesn't miss this' list for very short notification periods doesn't matter so much. Alan -- 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
Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy
On Wed, 7 Mar 2018 13:53:06 -0800 Linus Torvalds wrote: > I'm guessing this will go through Jon? Sounds like a fine guess to me; will apply shortly. Thanks, jon -- 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
Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy
On Wed, Mar 07, 2018 at 01:46:24PM -0800, Dave Hansen wrote: > > From: Dave Hansen > > 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 > Reviewed-by: Dan Williams > Cc: Thomas Gleixner > Cc: Greg Kroah-Hartman > Cc: Linus Torvalds > Cc: Alan Cox > Cc: Andrea Arcangeli > Cc: Andy Lutomirski > Cc: Kees Cook > Cc: Tim Chen > Cc: Alexander Viro > Cc: Andrew Morton > Cc: linux-doc@vger.kernel.org > Cc: Jonathan Corbet > Cc: Mark Rutland > --- > Reviewed-by: Greg Kroah-Hartman -- 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
Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy
On Wed, Mar 7, 2018 at 1:46 PM, Dave Hansen wrote: > > From: Dave Hansen > > 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 > Reviewed-by: Dan Williams > Cc: Thomas Gleixner > Cc: Greg Kroah-Hartman > Cc: Linus Torvalds > Cc: Alan Cox > Cc: Andrea Arcangeli > Cc: Andy Lutomirski > Cc: Kees Cook > Cc: Tim Chen > Cc: Alexander Viro > Cc: Andrew Morton > Cc: linux-doc@vger.kernel.org > Cc: Jonathan Corbet > Cc: Mark Rutland > --- > > 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 -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
Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy
That patch looks fine to me, avoiding any terms that might be misunderstood, and being pretty straightforward. I'm guessing this will go through Jon? Linus -- 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
[PATCH] [v2] docs: clarify security-bugs disclosure policy
From: Dave Hansen 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 Reviewed-by: Dan Williams Cc: Thomas Gleixner Cc: Greg Kroah-Hartman Cc: Linus Torvalds Cc: Alan Cox Cc: Andrea Arcangeli Cc: Andy Lutomirski Cc: Kees Cook Cc: Tim Chen Cc: Alexander Viro Cc: Andrew Morton Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet Cc: Mark Rutland --- 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) 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 _ -- 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
