linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Vegard Nossum <vegard.nossum@oracle.com>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org, Jiri Kosina <jkosina@suse.cz>,
	Solar Designer <solar@openwall.com>,
	Will Deacon <will@kernel.org>,
	linux-kernel@vger.kernel.org, Amit Shah <aams@amazon.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	David Woodhouse <dwmw@amazon.co.uk>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Laura Abbott <labbott@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Thorsten Leemhuis <linux@leemhuis.info>,
	Tyler Hicks <tyhicks@linux.microsoft.com>
Subject: Re: [PATCH v3 0/7] Documentation/security-bugs: overhaul
Date: Mon, 6 Mar 2023 07:35:34 +0100	[thread overview]
Message-ID: <ZAWJtvfnFWEjsIXd@1wt.eu> (raw)
In-Reply-To: <ZAWB5kwcG9IpWvE/@kroah.com>

On Mon, Mar 06, 2023 at 07:02:14AM +0100, Greg Kroah-Hartman wrote:
> Secondly, and the bigger one, I think we should just drop all of the
> references to linux-distros and oss-security entirely, as those are
> groups that are outside of our control and interaction and have
> different rules that we might not agree with.  They also just a tiny
> subset of Linux users and companies and as such do not really reflect
> the majority of where Linux is used anymore.

I'm wondering if instead they shouldn't just be mentioned as a warning
about the risk of leak or forced disclosure. We know that reporters may
find the address from various places, including various sites that may
enumerate the long list of potential contacts, and not just this doc.
It can be useful to have just a paragraph warning about the fact that
oss-sec is public and that linux-distros has this strict disclosure
policy without consideration for the availability of a fix, in order
to warn them to only contact such lists once the fix is available and
tested if they want to, but never before. Anything we can do to help
serious reporters (i.e. those who are really embarrassed with a bug,
not those who seek a Curiculum Vitae Enhancer) should be done. It's
always a stressful moment to report a security issue on a project,
you always fear that you might be doing an irreversible mistake, so
whatever info we can pass about the risks (or lack of) should be
welcome I guess.

Willy

  reply	other threads:[~2023-03-06  6:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-05 22:00 [PATCH v3 0/7] Documentation/security-bugs: overhaul Vegard Nossum
2023-03-05 22:00 ` [PATCH v3 1/7] Documentation/security-bugs: move from admin-guide/ to process/ Vegard Nossum
2023-03-06 12:35   ` Federico Vaga
2023-03-06 13:39   ` Carlos Bilbao
2023-03-06 14:04   ` Akira Yokosawa
2023-03-07  2:44   ` Yanteng Si
2023-03-12 15:00   ` Greg Kroah-Hartman
2023-03-05 22:00 ` [PATCH v3 2/7] Documentation/security-bugs: misc. improvements Vegard Nossum
2023-03-12 15:06   ` Greg Kroah-Hartman
2023-03-05 22:00 ` [PATCH v3 3/7] Documentation/security-bugs: improve security list section Vegard Nossum
2023-03-05 22:00 ` [PATCH v3 4/7] Documentation/security-bugs: add linux-distros and oss-security sections Vegard Nossum
2023-03-06  6:08   ` Greg Kroah-Hartman
2023-03-05 22:00 ` [PATCH v3 5/7] Documentation/security-bugs: add table of lists Vegard Nossum
2023-03-05 22:00 ` [PATCH v3 6/7] Documentation/security-bugs: clarify hardware vs. software vulnerabilities Vegard Nossum
2023-03-05 22:00 ` [PATCH v3 7/7] Documentation/security-bugs: document document design Vegard Nossum
2023-03-06  6:02 ` [PATCH v3 0/7] Documentation/security-bugs: overhaul Greg Kroah-Hartman
2023-03-06  6:35   ` Willy Tarreau [this message]
2023-03-06  6:42     ` Greg Kroah-Hartman
2023-03-06  9:42   ` Vegard Nossum
2023-03-06  7:11 ` Willy Tarreau
2023-03-06  8:47   ` Bagas Sanjaya
2023-03-06  8:48 ` Bagas Sanjaya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZAWJtvfnFWEjsIXd@1wt.eu \
    --to=w@1wt.eu \
    --cc=aams@amazon.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=dwmw@amazon.co.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavoars@kernel.org \
    --cc=jkosina@suse.cz \
    --cc=keescook@chromium.org \
    --cc=labbott@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@leemhuis.info \
    --cc=mchehab@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=solar@openwall.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=tyhicks@linux.microsoft.com \
    --cc=vegard.nossum@oracle.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).