linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: corbet@lwn.net, solar@openwall.com, will@kernel.org,
	peterz@infradead.org, gregkh@linuxfoundation.org,
	tyhicks@canonical.com, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] Documentation/security-bugs: provide more information about linux-distros
Date: Thu, 18 Jul 2019 23:41:13 -0400	[thread overview]
Message-ID: <20190719034113.GD4240@sasha-vm> (raw)
In-Reply-To: <201907181833.EF0D93C@keescook>

On Thu, Jul 18, 2019 at 06:51:07PM -0700, Kees Cook wrote:
>On Thu, Jul 18, 2019 at 08:39:19PM -0400, Sasha Levin wrote:
>> On Thu, Jul 18, 2019 at 03:00:55PM -0700, Kees Cook wrote:
>> > On Wed, Jul 17, 2019 at 07:11:03PM -0400, Sasha Levin wrote:
>> > > Provide more information about how to interact with the linux-distros
>> > > mailing list for disclosing security bugs.
>> > >
>> > > Reference the linux-distros list policy and clarify that the reporter
>> > > must read and understand those policies as they differ from
>> > > security@kernel.org's policy.
>> > >
>> > > Suggested-by: Solar Designer <solar@openwall.com>
>> > > Signed-off-by: Sasha Levin <sashal@kernel.org>
>> >
>> > Sorry, but NACK, see below...
>> >
>> > > ---
>> > >
>> > > Changes in v2:
>> > >  - Focus more on pointing to the linux-distros wiki and policies.
>> >
>> > I think this is already happening in the text. What specifically do you
>> > want described differently?
>>
>> The main issue was that there isn't anything pointing to the
>> linux-distros policies. The current text outlines a few of them ("add
>> [vs]", and "there should be an embargo period"), but it effectively just
>> gives out the linux-distros mailing address and tells the reporter to
>> contact it.
>
>The current text includes the wiki link, but yes, the anchor tag is not
>present at the wiki anymore. I would agree that's due for updating.
>
>I think reinforcing information to avoid past mistakes is appropriate
>here. Reports have regularly missed the "[vs]" detail or suggested
>embargoes that ended on Fridays, etc.

Right, but this is a sign that the reporter didn't read the wiki.
Explaining things like this encourages reporters to skip reading the
wiki and just send their report out.

>> > >  - Remove explicit linux-distros email.
>> >
>> > I don't like this because we had past trouble with notifications going
>> > to the distros@ list and leaking Linux-only flaws to the BSDs. As there
>> > isn't a separate linux-distros wiki, the clarification of WHICH list is
>> > needed.
>>
>> Why would removing the explicit linux-distros email encourage people to
>> send reports to it?
>
>What? No, I'm saying we should _keep_ linux-distros@... in our text so
>that people don't send to the wrong list.

But doesn't this just encourage mails being sent to linux-distros@
without the policies being followed? That was Alexander's concern at
least.

>> I also don't understand what you mean by "there isn't a separate
>> linux-distros wiki"? There is one, and I want to point the reporter
>> there.
>
>That URL is a combined page for two lists. The very fact that it's
>not obvious that there are two lists described there is exactly why I
>think we need to keep an explicit mention of which to use. There are
>two mailing lists described at the wiki URL:
>
>	      distros@lists.openwall.com
>	linux-distros@lists.openwall.com
>
>Sending to the distros@ list risks exposing Linux-only flaws to non-Linux
>distros. This has caused leaks in the past, and we do not want people
>guessing at which list they should use.
>
>Also note that nowhere on the openwall wiki is the email address
>actually spelled out; this is another reason to spell it out in our
>documentation: no misunderstanding.
>
>(And historically there WAS a specific linux-distros wiki:
>https://oss-security.openwall.org/wiki/mailing-lists/linux-distros
>but it redirects to the combined one now...)
>
>> > >  - Remove various explanations of linux-distros policies.
>> >
>> > I don't think there's value in removing the Tue-Thu comment, nor
>> > providing context for why distros need time. This has been a regular
>> > thing we've had to explain to researchers that aren't familiar with
>> > update procedures and publication timing.
>>
>> To be fair, the Tue-Thu comment is listed in the section describing how
>> to do coordination with linux-distros, and linux-distros don't have a
>> Tue-Thu policy. If it's a security@kernel.org policy then let's list it
>> elsewhere.
>
>It's a distro preference. Many researchers aren't thinking about the
>larger Linux ecosystem that has to consume fixes. It's not a _policy_,
>but it makes the researchers understand how to construct better embargoes.

If it's an accepted preference then we should just document it in a few
other places like the linux-distros@ wiki. My concern with this is that
it's not, and it's actually one of the only things Alexander pointed out
in this document as surprising.

--
Thanks,
Sasha

>> If you feel that there is a consensus around Tue-Thu let's just add it
>> to the linux-distros policy wiki, there's no point in listing random
>> policies from that wiki.
>
>I think it'd be a good idea to add that note also to the wiki, but I
>don't want it removed from our text because I have had to repeat that
>information regularly in the past.
>
>-- 
>Kees Cook

  reply	other threads:[~2019-07-19  3:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-17 23:11 [PATCH v2] Documentation/security-bugs: provide more information about linux-distros Sasha Levin
2019-07-18  9:40 ` Will Deacon
2019-07-18 14:14   ` Solar Designer
2019-07-18 22:00 ` Kees Cook
2019-07-19  0:39   ` Sasha Levin
2019-07-19  1:51     ` Kees Cook
2019-07-19  3:41       ` Sasha Levin [this message]
2019-07-19  8:42       ` Solar Designer
2019-07-23 22:23         ` Kees Cook

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=20190719034113.GD4240@sasha-vm \
    --to=sashal@kernel.org \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=solar@openwall.com \
    --cc=tyhicks@canonical.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).