Re: Closed list

[Solar Designer <solar () openwall com>]

Dan,

Thank you for your comments!  I had them in mind when I made the final
determination on the list that I've setup.

Josh wrote:
> > Should we require members use a mail address from their vendor? Letting
> > people use personal addresses creates an opportunity for people to remain
> > on a list when they are no longer a part of a given vendor (it also makes
> > it quite easy to know who represents a vendor).

"Good" employers, let alone non-commercial Open Source projects, don't
remove e-mail addresses when a person leaves.  Someone having an
@debian.org address does not mean they're currently with Debian.

On Fri, Apr 01, 2011 at 08:08:36PM -0400, Dan Rosenberg wrote:
> Yes, I think this should be a requirement for a closed coordination
> list

Yet I decided to allow some personal e-mail addresses for now, for the
reasons Mike has explained.  It takes me extra time to verify that a
person's non-vendor e-mail address is really "theirs", though.

> (as opposed to the more relaxed option #2).  In fact, I think
> membership to such a list should be restricted almost exclusively to
> distributions and downstream providers of third-party software.  It
> obviously makes sense to have distro security teams on a list, since a
> vulnerability in project XYZ will need to be coordinated among all of
> the distros.  However, most software projects only need access to
> information concerning their own project.  There's no reason one
> software project should gain access to vulnerability information about
> a completely unrelated project, and restricting membership to achieve
> that will at least help minimize the leakage that went on with the
> previous list.
>
> In a nutshell, I think this list needs to decide what its purpose is.
> If it's for coordination for vulnerability disclosure, then its
> membership should be kept to those who actually need to do the
> coordination.

Right.  So for now I setup a Linux distro security contacts list only,
as a hopefully better alternative to the long yet incomplete CC lists
that started to appear when vendor-sec ceased to exist.

> If it's for private (or semi-private) discussion of
> potentially sensitive research, knowledge sharing, etc., then its
> membership should be expanded to include representation from software
> vendors and researchers.

Right, although I'm not sure about software vendors.  I think there's
usually just one non-distro software vendor for whom a given issue is
relevant (the upstream), so it can simply be CC'ed.  For example, on the
old vendor-sec we had X and Samba, and I don't recall any discussion in
which both participated at once.

Alexander