[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 16 May 2022 18:54:00 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: oss-security@...ts.openwall.com
Cc: Solar Designer <solar@...nwall.com>
Subject: Re: linux-distros list policy and Linux kernel
On Mon, May 16, 2022 at 10:43:33AM -0300, Thadeu Lima de Souza Cascardo wrote:
> On Mon, May 16, 2022 at 03:12:20PM +0200, Jason A. Donenfeld wrote:
> > Hi Alexander,
> >
> > I think a lot of this depends on what you feel the primary value in
> > distros@ is.
> >
> > I always thought its primary purpose was to centralize embargoed
> > vulnerability reports, using its presence as *the* de facto forum for
> > that, in order to receive nearly all embargoed bugs. Then, those bugs
> > become subject to the distros@ 14-day disclosure policies. Seen this
> > way, distros@ is a mechanism for ensuring that bugs eventually *do*
> > become disclosed, rather than languishing in embarrassed vendor
> > purgatory forever.
> >
> > Maybe I'm far off, though, so it'd be interesting to learn if you have a
> > different idea of its value.
> >
>
> [...]
>
> > And anyway, practically speaking, security@...nel.org's disclosure
> > deadline is usually something like 7 days, which is pretty short, so for
> > people who misread the documentation, at most they'll only be miffed
> > about a few days, rather than a few months.
> >
>
> Though I want to add a little more to this discussion, I think this needs
> clarification and is really one of the main pain points here, in my opinion.
>
> "Although our preference is to release fixes for publicly undisclosed bugs
> as soon as they become available, this may be postponed at the request of
> the reporter or an affected party for up to 7 calendar days from the start
> of the release process"
>
> This is about the fixes, not the security report. As I read it, once a fix is
> developed/reviewed/accepted, kernel maintainers/developers may hold the *fix*
> release up to 7 days.
Correct.
> Right in the next paragraph, though:
>
> "While embargoed information may be shared with trusted individuals in
> order to develop a fix, such information will not be published alongside
> the fix or on any other disclosure channel without the permission of the
> reporter. This includes but is not limited to the original bug report
> and followup discussions (if any), exploits, CVE information or the
> identity of the reporter."
>
> This means that it's now up to the reporter to disclose any information if they
> want to. They may never disclose it. They may wait for someone else to disclose
> it. Or decide to disclose it immediately.
That is correct.
> Now, as you said earlier in your message (which is why I kept that excerpt),
> linux-distros ends up having such a role where reports sent to it should be
> made public in no more than 14 days. But there is no such mechanism on
> security@...nel.org rules as documented at
> Documentation/admin-guide/security-bugs.rst, as I understand it.
That is correct, the kernel security "team" puts no rules or
requirements on anyone who submits stuff to us. If they wish to
disclose things or not after the fix is merged into Linus's tree, that
is up to them.
thanks,
greg k-h
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
