[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZAWomdmSXViNAZVb@debian.me>
Date: Mon, 6 Mar 2023 15:47:21 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Willy Tarreau <w@....eu>, Vegard Nossum <vegard.nossum@...cle.com>
Cc: Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
Jiri Kosina <jkosina@...e.cz>,
Solar Designer <solar@...nwall.com>,
Will Deacon <will@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org, Amit Shah <aams@...zon.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
David Woodhouse <dwmw@...zon.co.uk>,
"Gustavo A. R. Silva" <gustavoars@...nel.org>,
Kees Cook <keescook@...omium.org>,
Laura Abbott <labbott@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Thorsten Leemhuis <linux@...mhuis.info>,
Tyler Hicks <tyhicks@...ux.microsoft.com>
Subject: Re: [PATCH v3 0/7] Documentation/security-bugs: overhaul
On Mon, Mar 06, 2023 at 08:11:38AM +0100, Willy Tarreau wrote:
> - I'm not seeing anywhere that the security list is *exclusively*
> for kernel issues. That might explain why about once a week or so
> we receive messages like "there's a bug in that userland tool" or
> "we've found an XSS issue on your website". It's written that kernel
> bugs should be reported to the security list but I think we should
> strengthen that by adding "This list is exclusively used for Linux
> kernel security reports, please do not report issues affecting any
> other component there".
I think the wording would be "Please report security bugs against Linux
kernel to security@...nel.org list. Security bugs against userspace
applications should be reported to appropriate channels for affected
applications instead."
> - it's quite frequent that reporters post from dummy addresses,
> looking like randomly generated ones (we even had one looking
> like a smiley). It doesn't help to communicate with them at all.
> I can understand how some working as consultants for a customer
> would want to avoid disclosing a particular relation between their
> finding and their customer, but at least they should indicate how
> they should be called. I.e. "call me Margarett" is not difficult
> and simplifies exchanges when the address is "69236836@...mple.com".
> And often we see at the end that they're willing to provide a real
> name to be credited for the finding, so most likely starting with
> this real name could be easier.
>
Something like temporary addresses (à la maildrop or mail.gw)?
> - it's more a discussion for the list itself, but the wording continues
> to make one think that the reporter should expect the list members to
> develop a patch, while in practise the first thing that's asked is
> "since you've studied the problem well, do you happen to have a patch?".
> And it happened a few times that in response we got "oops sorry, I
> analysed it wrong, there's no issue there". I think the text should
> emphasize more on encouraging submitters to complete their work with
> a patch proposal (that's also helpful to confirm an analysis). And
> conversely I think that reports for non-immediately exploitable issues
> that are found by code analyzers (and almost always come without a
> patch) should not be sent to this list and should be discussed and
> addressed publicly instead. It's more efficient and allows more
> knowledgeable participants to have their say on the root cause of
> the problem and its possible solutions. That's of course not always
> the case, but common sense should prevail here.
I think the wording would be "It is preferrable to have a proposed patch
for the bug you report. See
Documentation/process/submitting-patches.rst for details on how to
submit patches."
Thanks.
--
An old man doll... just what I always wanted! - Clara
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists