[gentoo-dev] GLEP 14 follow-up / security project

[Marius Mauch]

Hi all,

as GLEP 14 has been accepted yesterday I made a little writeup that
deals with the upcoming security project and the handling of security
bugs. Some of the points mentioned here have been touched in
#gentoo-security, this is basically a follow-up of that discussion and
the discussion about GLEP 14, as the GLSA release process has to be
changed for the final implementation of GLEP 14 (for those joining late:
http://www.gentoo.org/proj/en/glep/glep-0014.html).
This is just a (not very well thought) proposal, nothing definite. But
I'd like to get this off the ground ASAP, as classes start in 3 weeks
and will need a lot of time from me then.

Basic idea for the handling of security bugs:

Security bugs should be kept in bugzilla, but to automate the generation
of GLSAs we need a special format somehow, if we use keywords, comments
or something different for that is open. To maintain the integrity of
that format the direct editing of these bugs should be limited to a few
people if possible.
The actual filing and editing of these bugs should be done with a new
interface that is specially designed for security bugs and GLSA
information. Once a security bug is marked as fixed a GLSA generation
script is run that generates the GLSA, GPG-signs it (depending on
policy) and distributes it on mailing lists, http- and rsync-servers.
The update script then can take the GLSAs from /usr/portage/glsa or the
http repository (to avoid unneeded syncs just to get the GLSA).

course of action:
- form the security project and find a lead
- define the terms of reference for the security team
- specify the format of a GLSA / finalize the DTD
- define a policy for GLSAs
- write a project website, including policy
- define a special format for security bugs that allows script based
parsing
- code necessary extensions for bugzilla / edit bugzilla config to
handle security bugs different
- code an interface to bugzilla for entering security bugs using the
defined format
- code the GLSA generation script
- finish the update script and include it in portage/gentoolkit or a new
package
- (update old GLSAs)

special bugzilla handling for security bugs:
- only allow a few people to file/close/edit them directly (to maintain
the special format) if possible
- run the generation script when a security bug is marked as fixed
(maybe define other actions for other resolutions ??)

needed tools:
- bugzilla extension ??
- GLSA generation script which does:
	* convert the bugzilla/mysql data to plaintext and XML
	* signs the GLSA (details depend on policy)
	* sends the GLSA to a set of defined mailinglist
	* commits the GLSA into a repository from where it is uploaded/copied
to the gentoo-x86 tree and the project website repository (for online
checking)
	* sends a notice to the forum moderators (or post directly ??)
- update script (which can be integrated into portage later), mostly
done
- bugzilla interface site

idea for GLSA policy:
- everyone who should be able to issue a GLSA needs a GPG key that is
signed by a master security project key
- the GLSA is signed with the master security project key and the key of
the developer who closed the bug
- before a bug is closed at least one other security project member has
to confirm it

I'm sure I missed a lot of things but I think the general idea should be
clear. Everything is open for discussion.
So, what do you think about this?

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.