Fedora security announce and discussion lists

[Nathan G. Grennan]

   I strongly believe that Fedora needs lists for announcement and
discussion of security issues. This is to prevent the potential
nightmare of the Core gets patched as usual by Red Hat, but packages by
outside maintainers are stale for much longer because some maintainer
isn't on every security mailing list. I think the announcement list
should be low noise and controlled by someone at Red Hat, or a trusted
member of the community. Just make announcements of security problems in
a similar way to Red Hat's errata notes for security issues. Then there
can be a second list to discuss them to get the fixes working and tested
ASAP.

   This idea came to be because of the issue with running things from
rawhide has always been a security risk. You never know when the
maintainer will make a new rawhide package with the necessary security
fix for the latest exploits. This especially becomes an issue for things
like Fedora Alternatives, Fedora Extras, and Fedora Legacy. Along with
maintainers outside of Red Hat doing Fedora Core packages.

   I am a strong advocate of full disclosure. I think both lists should
be open to the public for subscription. This is meant to be a community
project and I think the whole community should be able to stay informed.
I have heard others mention they are generally for full disclosure, but
not in all cases. I don't see how you can exactly draw a line. The idea
behind full disclosure is to motivate whoever is responsible to get it
done ASAP. I also think in general full disclosure is less of an issue
in most cases, because most exploits effect all distributions or
operating systems that use a certain piece of software, not just a
certain distribution. We will be more reacting to outside information
than reacting to problems we discover ourselves. I think that informing
all the the community about how we are reacting to outside information
on the lists outweighs the risk posed by disclosing information we
discover ourselves.

   Another idea I just had while writing this is for a security-audit
team be created from members of the community to volunteer to review
code for exploits. Also verify that patches for exploits were while not
creating new exploits.