mailing list archives
Re: running the distros lists
From: Solar Designer <solar () openwall com>
Date: Thu, 15 Mar 2012 00:54:12 +0400
On Wed, Mar 14, 2012 at 01:42:23PM -0600, Kurt Seifried wrote:
Can we also maintain a public database of upstream contacts? I seem to
remember a few different efforts to do this but can't find anything
We have this wiki page:
It currently lists Apache, Asterisk, ..., Xine, X.Org - just to give an
idea of what projects chose to add themselves or were added. By all
means, please help keep this wiki page current and use it.
We also have:
This would save a ton of time. It would of course have to be
maintained (maybe a scheme like emailing the people listed every few
months and offering a "click here to confirm you're still the security
contact" and a "click here to be removed as the contact" to help keep it
up to date).
Well, we don't have that currently, and I'm not sure if it'd work well
in practice or not. I imagine that some upstreams would be offended by
the automated messages, yet they could also be offended by not being
notified of an issue affecting their software (and more importantly
their users would be affected).
Also things like PGP keys/etc would be nice to have in this.
Right. Please feel free to add PGP key info to the wiki pages above.
It strikes me that this would actually be a valuable project for
Mitre, similar to CPE, maybe the "SCE" ("Security Contact Enumeration")?
As anyone trying to notify multiple upstreams knows, it can be a
horribly painful process.
Yes, but my gut feeling is that identifying the right set of projects to
notify is at least as difficult and time-consuming as finding their
current contact info is. Of course, anything we can do to make any of
the steps easier may be of help.
Kurt - how about my original request for help running the list, though?
Even if you somehow don't volunteer to notify upstreams (and others),
making sure that every issue gets a CRD proposed for it ASAP will be of
help. Can I at least count on you doing that? ;-) And maybe someone
else will volunteer for other sub-tasks (although a per-vulnerability
rather than per-sub-task split between the several responsible list
members could work better, I think).