From: Dave Hansen <[email protected]>
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 <[email protected]>
Reviewed-by: Dan Williams <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Alan Cox <[email protected]>
Cc: Andrea Arcangeli <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Tim Chen <[email protected]>
Cc: Alexander Viro <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: [email protected]
Cc: Jonathan Corbet <[email protected]>
Cc: Mark Rutland <[email protected]>
---
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
------------
_
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
On Wed, Mar 7, 2018 at 1:46 PM, Dave Hansen <[email protected]> wrote:
>
> From: Dave Hansen <[email protected]>
>
> 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 <[email protected]>
> Reviewed-by: Dan Williams <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Cc: Linus Torvalds <[email protected]>
> Cc: Alan Cox <[email protected]>
> Cc: Andrea Arcangeli <[email protected]>
> Cc: Andy Lutomirski <[email protected]>
> Cc: Kees Cook <[email protected]>
> Cc: Tim Chen <[email protected]>
> Cc: Alexander Viro <[email protected]>
> Cc: Andrew Morton <[email protected]>
> Cc: [email protected]
> Cc: Jonathan Corbet <[email protected]>
> Cc: Mark Rutland <[email protected]>
> ---
>
> 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 <[email protected]>
-Kees
--
Kees Cook
Pixel Security
On Wed, Mar 07, 2018 at 01:46:24PM -0800, Dave Hansen wrote:
>
> From: Dave Hansen <[email protected]>
>
> 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 <[email protected]>
> Reviewed-by: Dan Williams <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Cc: Linus Torvalds <[email protected]>
> Cc: Alan Cox <[email protected]>
> Cc: Andrea Arcangeli <[email protected]>
> Cc: Andy Lutomirski <[email protected]>
> Cc: Kees Cook <[email protected]>
> Cc: Tim Chen <[email protected]>
> Cc: Alexander Viro <[email protected]>
> Cc: Andrew Morton <[email protected]>
> Cc: [email protected]
> Cc: Jonathan Corbet <[email protected]>
> Cc: Mark Rutland <[email protected]>
> ---
>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
On Wed, 7 Mar 2018 13:53:06 -0800
Linus Torvalds <[email protected]> wrote:
> I'm guessing this will go through Jon?
Sounds like a fine guess to me; will apply shortly.
Thanks,
jon
On Wed, 07 Mar 2018 13:46:24 -0800
Dave Hansen <[email protected]> wrote:
> From: Dave Hansen <[email protected]>
>
> 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
On Fri, Mar 9, 2018 at 12:45 PM, Alan Cox <[email protected]> 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
Hi!
On Fri 2018-03-09 13:15:31, Linus Torvalds wrote:
> On Fri, Mar 9, 2018 at 12:45 PM, Alan Cox <[email protected]> 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
On Sun, Apr 22, 2018 at 3:00 AM, Pavel Machek <[email protected]> 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