[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190802092431.GB12845@1wt.eu>
Date: Fri, 2 Aug 2019 11:24:31 +0200
From: Willy Tarreau <w@....eu>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
Jonathan Corbet <corbet@....net>, security@...nel.org,
linux-doc@...r.kernel.org, Jiri Kosina <jkosina@...e.com>,
Mauro Carvalho Chehab <mchehab+samsung@...nel.org>
Subject: Re: [PATCH] Documentation/admin-guide: Embargoed hardware security
issues
On Fri, Aug 02, 2019 at 08:57:29AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Aug 02, 2019 at 06:49:08AM +0200, Willy Tarreau wrote:
> > Hi Greg, Thomas,
> >
> > On Thu, Jul 25, 2019 at 03:01:13PM +0200, Greg Kroah-Hartman wrote:
> > > +The list is encrypted and email to the list can be sent by either PGP or
> > > +S/MIME encrypted and must be signed with the reporter's PGP key or S/MIME
> > > +certificate. The list's PGP key and S/MIME certificate are available from
> > > +https://www.kernel.org/....
> >
> > Just thinking, wouldn't it be useful to strongly encourage that the
> > document should be in plain text format ? Otherwise the door remains open
> > for sending you a self-extractable EXE file which contains an encrypted
> > Word doc, which is not the most useful to handle especially to copy-paste
> > mitigation code nor to comment on. Even some occasional PDFs we've seen
> > on the sec@k.o list were sometimes quite detailed but less convenient
> > than the vast majority of plain text ones, particularly when it comes
> > to quoting some parts.
>
> What document are you referring to here? This just describes how the
> encrypted mailing list is going to work, not anything else.
I mean the document describing the issue that the reporter is going to
send to the mailing list.
> But yes, we have had some "encrypted pdfs" be sent to us recently that
> no one can decrypt unless they run Windows or do some really crazy hacks
> with the gstreamer pipeline. But that's separate from this specific
> mailing list, we can always just tell people to not do foolish things if
> that happens again (like we did in this case.)
That was exactly my point :-) Just like the process indicates what list
to contact to report an issue, it can also indicate the preferred way to
efficiently report these issues.
Willy
Powered by blists - more mailing lists