Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170731205316.GA12811@openwall.com>
Date: Mon, 31 Jul 2017 22:53:16 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: CoreOS membership to linux-distros (updated)

On Fri, Jul 21, 2017 at 03:26:47PM +0200, Solar Designer wrote:
> I intend to add CoreOS to linux-distros in early August unless there are
> any well-reasoned objections by then.

I've just added CoreOS to linux-distros.

On Tue, Jul 18, 2017 at 02:56:23PM -0700, Euan Kemp wrote:
> Based on your previous messages, it sounds like it???s expected for us to
> inherit 'primary' for the administrative tasks of:
> > 1. Promptly review new issue reports for meeting the list's requirements and confirm receipt of the report and, when necessary, inform the reporter of any issues with their report (e.g., obviously not actionable by the distros) and request and/or propose any required yet missing information (most notably, a tentative public disclosure date) - primary: CloudLinux, backup: vacant
> > 2. If the proposed public disclosure date is not within list policy, insist on getting this corrected and propose a suitable earlier date - primary: CloudLinux, backup: vacant

Off-list, CloudLinux kindly offered this:

On Sun, Jul 23, 2017 at 06:15:23AM -0700, Igor Seletskiy wrote:
> We can pickup #3 & #6 as #1 & #2 are picked up by CoreOS.

On Tue, Jul 18, 2017 at 02:56:23PM -0700, Euan Kemp wrote:
> I???ll also volunteer us for the administrative task of:
> > 6. If multiple issues are reported at once, see if any of them can reasonably be made public sooner than the rest, and if so help untangle them and stay on top of their disclosure process
> 
> We???ll be happy to be on the lookout for possible conflation of issues
> and kick off discussion if we think something can be broken up.

Maybe Igor had overlooked the clash on #6, but anyway this combination
resulted in:

1. Promptly review new issue reports for meeting the list's requirements
and confirm receipt of the report and, when necessary, inform the
reporter of any issues with their report (e.g., obviously not actionable
by the distros) and request and/or propose any required yet missing
information (most notably, a tentative public disclosure date)
- primary: CoreOS, backup: Oracle

2. If the proposed public disclosure date is not within list policy,
insist on getting this corrected and propose a suitable earlier date
- primary: CoreOS, backup: CloudLinux

3. Evaluate if the issue (or one of the issues) is effectively already
public (e.g., a fix is committed upstream with a descriptive message)
or/and is low severity and thus the report (or its portion pertaining to
the issue) should be made public right away for one or both of these
reasons, get a few other list members to confirm this understanding, and
if there are no objections then communicate this strong preference to
the reporter
- primary: CloudLinux, backup: vacant

6. If multiple issues are reported at once, see if any of them can
reasonably be made public sooner than the rest, and if so help untangle
them and stay on top of their disclosure process
- primary: CoreOS, backup: CloudLinux

This looks fine to me.

However, many distros still haven't picked up a task, and many tasks are
not picked up by any distro.  That should change.

Alexander

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.