[PATCH] Documentation/security-bugs: Explain why plain text is preferred

[PATCH] Documentation/security-bugs: Explain why plain text is preferred

[Kees Cook]

The security contact list gets regular reports contained in archive
attachments. This tends to add some back-and-forth delay in dealing with
security reports since we have to ask for plain text, etc.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 Documentation/admin-guide/security-bugs.rst | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
index dcd6c93c7aac..c32eb786201c 100644
--- a/Documentation/admin-guide/security-bugs.rst
+++ b/Documentation/admin-guide/security-bugs.rst
@@ -21,11 +21,18 @@ understand and fix the security vulnerability.
 
 As it is with any bug, the more information provided the easier it
 will be to diagnose and fix.  Please review the procedure outlined in
-admin-guide/reporting-bugs.rst if you are unclear about what
+:doc:`reporting-bugs` if you are unclear about what
 information is helpful.  Any exploit code is very helpful and will not
 be released without consent from the reporter unless it has already been
 made public.
 
+Please send plain text emails without attachments where possible.
+It is much harder to have a context-quoted discussion about a complex
+issue if all the details are hidden away in attachments.  Think of it like a
+:doc:`regular patch submission <../process/submitting-patches>`
+(even if you don't have a patch yet): describe the problem and impact, list
+reproduction steps, and follow it with a proposed fix, all in plain text.
+
 Disclosure and embargoed information
 ------------------------------------
 
-- 
2.25.1


-- 
Kees Cook

Re: [PATCH] Documentation/security-bugs: Explain why plain text is preferred

[Will Deacon]

On Thu, Jul 09, 2020 at 11:11:30AM -0700, Kees Cook wrote:
> The security contact list gets regular reports contained in archive
> attachments. This tends to add some back-and-forth delay in dealing with
> security reports since we have to ask for plain text, etc.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  Documentation/admin-guide/security-bugs.rst | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
> index dcd6c93c7aac..c32eb786201c 100644
> --- a/Documentation/admin-guide/security-bugs.rst
> +++ b/Documentation/admin-guide/security-bugs.rst
> @@ -21,11 +21,18 @@ understand and fix the security vulnerability.
>  
>  As it is with any bug, the more information provided the easier it
>  will be to diagnose and fix.  Please review the procedure outlined in
> -admin-guide/reporting-bugs.rst if you are unclear about what
> +:doc:`reporting-bugs` if you are unclear about what
>  information is helpful.  Any exploit code is very helpful and will not
>  be released without consent from the reporter unless it has already been
>  made public.
>  
> +Please send plain text emails without attachments where possible.
> +It is much harder to have a context-quoted discussion about a complex
> +issue if all the details are hidden away in attachments.  Think of it like a
> +:doc:`regular patch submission <../process/submitting-patches>`
> +(even if you don't have a patch yet): describe the problem and impact, list
> +reproduction steps, and follow it with a proposed fix, all in plain text.
> +

Acked-by: Will Deacon <will@kernel.org>

Hopefully "plain text" implies unencrypted as much as it does "not html".

Will

Re: [PATCH] Documentation/security-bugs: Explain why plain text is preferred

[Kees Cook]

On Thu, Jul 09, 2020 at 09:42:56PM +0100, Will Deacon wrote:
> On Thu, Jul 09, 2020 at 11:11:30AM -0700, Kees Cook wrote:
> > The security contact list gets regular reports contained in archive
> > attachments. This tends to add some back-and-forth delay in dealing with
> > security reports since we have to ask for plain text, etc.
> > 
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > ---
> >  Documentation/admin-guide/security-bugs.rst | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
> > index dcd6c93c7aac..c32eb786201c 100644
> > --- a/Documentation/admin-guide/security-bugs.rst
> > +++ b/Documentation/admin-guide/security-bugs.rst
> > @@ -21,11 +21,18 @@ understand and fix the security vulnerability.
> >  
> >  As it is with any bug, the more information provided the easier it
> >  will be to diagnose and fix.  Please review the procedure outlined in
> > -admin-guide/reporting-bugs.rst if you are unclear about what
> > +:doc:`reporting-bugs` if you are unclear about what
> >  information is helpful.  Any exploit code is very helpful and will not
> >  be released without consent from the reporter unless it has already been
> >  made public.
> >  
> > +Please send plain text emails without attachments where possible.
> > +It is much harder to have a context-quoted discussion about a complex
> > +issue if all the details are hidden away in attachments.  Think of it like a
> > +:doc:`regular patch submission <../process/submitting-patches>`
> > +(even if you don't have a patch yet): describe the problem and impact, list
> > +reproduction steps, and follow it with a proposed fix, all in plain text.
> > +
> 
> Acked-by: Will Deacon <will@kernel.org>

Thanks!

> 
> Hopefully "plain text" implies unencrypted as much as it does "not html".

I decided not to write a paragraph about how security@ isn't a
role-account with a separate GPG key etc etc. Those cases are rare
enough that I don't think it (yet) warrants a paragraph here. I want to
strike a balance between "all your questions are answered" and "there's
too much here for me to find the answer to my question". :)

-- 
Kees Cook

Re: [PATCH] Documentation/security-bugs: Explain why plain text is preferred

[Jiri Kosina]

On Thu, 9 Jul 2020, Kees Cook wrote:

> The security contact list gets regular reports contained in archive
> attachments. This tends to add some back-and-forth delay in dealing with
> security reports since we have to ask for plain text, etc.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>

Acked-by: Jiri Kosina <jkosina@suse.cz>

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] Documentation/security-bugs: Explain why plain text is preferred

[Gustavo A. R. Silva]

On 7/9/20 13:11, Kees Cook wrote:
> The security contact list gets regular reports contained in archive
> attachments. This tends to add some back-and-forth delay in dealing with
> security reports since we have to ask for plain text, etc.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>

Acked-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Thanks
--
Gustavo

Re: [PATCH] Documentation/security-bugs: Explain why plain text is preferred

[Willy Tarreau]

On Thu, Jul 09, 2020 at 09:42:56PM +0100, Will Deacon wrote:
> Acked-by: Will Deacon <will@kernel.org>
> 
> Hopefully "plain text" implies unencrypted as much as it does "not html".

I would have liked "(i.e. not html)" to be added after "plain text", but
I figured that those who do that often don't even know what this means
so that will probably not help them avoid their messages being stored
into a spambox :-/

Acked-by: Willy Tarreau <w@1wt.eu>

Willy

Re: [PATCH] Documentation/security-bugs: Explain why plain text is preferred

[Greg Kroah-Hartman]

On Thu, Jul 09, 2020 at 11:11:30AM -0700, Kees Cook wrote:
> The security contact list gets regular reports contained in archive
> attachments. This tends to add some back-and-forth delay in dealing with
> security reports since we have to ask for plain text, etc.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>

Thanks for this, that will hopefully keep us from having to say the same
thing over and over :)

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH] Documentation/security-bugs: Explain why plain text is preferred

[Peter Zijlstra]

On Thu, Jul 09, 2020 at 11:11:30AM -0700, Kees Cook wrote:
> The security contact list gets regular reports contained in archive
> attachments. This tends to add some back-and-forth delay in dealing with
> security reports since we have to ask for plain text, etc.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  Documentation/admin-guide/security-bugs.rst | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
> index dcd6c93c7aac..c32eb786201c 100644
> --- a/Documentation/admin-guide/security-bugs.rst
> +++ b/Documentation/admin-guide/security-bugs.rst
> @@ -21,11 +21,18 @@ understand and fix the security vulnerability.
>  
>  As it is with any bug, the more information provided the easier it
>  will be to diagnose and fix.  Please review the procedure outlined in
> -admin-guide/reporting-bugs.rst if you are unclear about what
> +:doc:`reporting-bugs` if you are unclear about what

I can do 'gf' on Documentation/admin-guide/reporting-bugs.rst, I can do
didly squat with crap like :doc:'reporting-bugs'.

NAK

>  information is helpful.  Any exploit code is very helpful and will not
>  be released without consent from the reporter unless it has already been
>  made public.
>  
> +Please send plain text emails without attachments where possible.
> +It is much harder to have a context-quoted discussion about a complex
> +issue if all the details are hidden away in attachments.  Think of it like a
> +:doc:`regular patch submission <../process/submitting-patches>`

More unusable references.

> +(even if you don't have a patch yet): describe the problem and impact, list
> +reproduction steps, and follow it with a proposed fix, all in plain text.
> +

You forgot to mention that opening complex file formats is a security
risk all of its own.

Re: [PATCH] Documentation/security-bugs: Explain why plain text is preferred

[Peter Zijlstra]

On Thu, Jul 09, 2020 at 09:42:56PM +0100, Will Deacon wrote:
> On Thu, Jul 09, 2020 at 11:11:30AM -0700, Kees Cook wrote:
> > The security contact list gets regular reports contained in archive
> > attachments. This tends to add some back-and-forth delay in dealing with
> > security reports since we have to ask for plain text, etc.
> > 
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > ---
> >  Documentation/admin-guide/security-bugs.rst | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
> > index dcd6c93c7aac..c32eb786201c 100644
> > --- a/Documentation/admin-guide/security-bugs.rst
> > +++ b/Documentation/admin-guide/security-bugs.rst
> > @@ -21,11 +21,18 @@ understand and fix the security vulnerability.
> >  
> >  As it is with any bug, the more information provided the easier it
> >  will be to diagnose and fix.  Please review the procedure outlined in
> > -admin-guide/reporting-bugs.rst if you are unclear about what
> > +:doc:`reporting-bugs` if you are unclear about what
> >  information is helpful.  Any exploit code is very helpful and will not
> >  be released without consent from the reporter unless it has already been
> >  made public.
> >  
> > +Please send plain text emails without attachments where possible.
> > +It is much harder to have a context-quoted discussion about a complex
> > +issue if all the details are hidden away in attachments.  Think of it like a
> > +:doc:`regular patch submission <../process/submitting-patches>`
> > +(even if you don't have a patch yet): describe the problem and impact, list
> > +reproduction steps, and follow it with a proposed fix, all in plain text.
> > +
> 
> Acked-by: Will Deacon <will@kernel.org>
> 
> Hopefully "plain text" implies unencrypted as much as it does "not html".

Or that RST crap :-(

Re: [PATCH] Documentation/security-bugs: Explain why plain text is preferred

[Jonathan Corbet]

On Thu, 9 Jul 2020 11:11:30 -0700
Kees Cook <keescook@chromium.org> wrote:

> The security contact list gets regular reports contained in archive
> attachments. This tends to add some back-and-forth delay in dealing with
> security reports since we have to ask for plain text, etc.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  Documentation/admin-guide/security-bugs.rst | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)

Applied, thanks.

jon