Re: accepting new members to (linux-)distros lists

[Anthony Liguori <anthony () codemonkey ws>]

Hi Solar,

On Wed, Jun 28, 2017 at 1:02 PM, Solar Designer <solar () openwall com> wrote:
> Hi,
>
> I have finally specified the criteria for accepting new members to the
> (linux-)distros lists.  I intend to process the requests, which are to
> be posted to new threads each (one thread per distro wanting to join).
>
> I put quite some thought (and experience so far) into these criteria,
> but I welcome any comments and suggested changes this community might
> have.  The list of criteria will be maintained on the wiki:
>
> http://oss-security.openwall.org/wiki/mailing-lists/distros#membership-criteria
>
> Currently, to be eligible for (linux-)distros list membership, your
> distro should:
>
> 1. Be an actively maintained Unix-like operating system distro with
> substantial use of Open Source components
>
> 2. Have a userbase not limited to your own organization
>
> 3. Have a publicly verifiable track record, dating back at least 1 year
> and continuing to present day, of fixing security issues (including some
> that had been handled on (linux-)distros, meaning that membership would
> have been relevant to you) and releasing the fixes within 10 days (and
> preferably much less than that) of the issues being made public (if it
> takes you ages to fix an issue, your users wouldn't substantially
> benefit from the additional time, often around 7 days and sometimes up
> to 14 days, that list membership could give you)
>
> 4. Not be (only) downstream or a rebuild of another distro (or else we
> need convincing additional justification of how the list membership
> would enable you to release fixes sooner, presumably not relying on the
> upstream distro having released their fixes first?)
>
> 5. Be a participant and preferably an active contributor in relevant
> public communities (most notably, if you're not watching for issues
> being made public on oss-security, which are a superset of those that
> had been handled on (linux-)distros, then there's no valid reason for
> you to be on (linux-)distros)
>
> 6. Accept the list policy:
> http://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-members
> (also quoted below)
>
> 7. Be able and willing to contribute back, preferably in specific ways
> announced in advance (so that you're responsible for a specific area and
> so that we know what to expect from which member), and demonstrate
> actual contributions once you've been a member for a while:
> http://oss-security.openwall.org/wiki/mailing-lists/distros#contributing-back
> (also quoted below)
>
> 8. Be able and willing to handle PGP-encrypted e-mail
>
> 9. Have someone already on the private list, or at least someone else
> who has been active on oss-security for years but is not affiliated with
> your distro nor your organization, vouch for at least one of the people
> requesting membership on behalf of your distro (then that one
> vouched-for person will be able to vouch for others on your team, in
> case you'd like multiple people subscribed)
>
> Membership requests should provide answers per each of these criteria.
>
> I came up with many current tasks/roles that a new or existing member
> could usefully help with, thereby contributing to the team effort.
> Currently the wiki page lists a total of 18 such items: 5 technical and
> 13 administrative.  I'd prefer that new membership requests include
> specifics on what the new member will contribute - this can be work on
> some of these 18 items or/and something else.

I've been thinking about this list of items and also some of the
challenges of Stack Clash.  Something that frequently came up was
uncertainty about what the current set of patches were and there was
also lack of clarity on dates.

I think a lot of the administrative tasks outlined can be better
handled through a system other than email.

What do you think about having a public bugzilla (or similar system)
where tracked issues are kept as private bugs?  I think this could be
hosted in a way that everyone felt comfortable with (ensuring enough
people had SSH access to for audit purposes).  It's relatively easy to
stick everything behind SSL.

In addition to helping to make sure there's clear information (like a
summary, current patches, etc), I think the Project Zero approach of
making a private bug public post-embargo helps share information and
provide more transparency after the event.

I'm not suggesting that a bug tracker eliminate the discussions on the
list, but really just supplement it.  If there's interest in this, we
would be very willing to set it up and deal with the hosting aspect of
it.

Thoughts?

Regards,

Anthony Liguori