GLSA Release Plan 0.1
=====================

As there is a lot of confusion about this subject I'll try to outline the vision
I had when I wrote GLEP 14. I thought the GLEP had enough details, but it seems obvious
that this is not the case. This can be used as a base for further discussions.
So, how would the new release process work:

1.) a dev writes a XML GLSA (using a normal editor or a special tool like GLSAMaker)
2.) (if desired) dev copies the GLSA to a restricted box, so only authorized
	devs can publish GLSAs
3.) the dev runs a posting script on that box which does the following:
	a) ensure syntactical correctness of the GLSA (using xmllint or similar)
	b) check for semantical errors (like non-existant packages/versions, wrong dates)
	c) gpg-sign the XML GLSA with the developers key (if desired: sign it with a 
		generic security-team key)
	d) cvs commit the XML GLSA and the signature to gentoo-x86/glsa/ using a defined
		naming scheme (I suggest using the GLSA ID as filename)
	e) cvs commit the XML GLSA and the signature to a subdir of the security website
		using the same naming scheme
	f) edit the GLSA index page to include the new GLSA
	g) (if desired) generates a plaintext version of the GLSA and signs it, then
		sending a mail with XML and plaintext GLSAs to a set of predefined mailing
		lists.
4.) after that the GLSA is available over the website (can we get the raw 
	XML of there ?) and over the rsync tree, so all users will get it on their
	next `emerge --sync`

This would require virtually no additional infrastructure changes, only the 
website, the gentoo-x86/glsa dir and the installation of the posting script
(I assume xmllint, gpg, cvs and other tools required by the script are available).
Also all actions will be executed with the dev account, so no special accounts 
are needed.

Now the original point of the GLEP ("emerge --security") can continue:
(I'll use the term update tool for the functionality of `emerge --security`)

1.) the update tool checks for available GLSAs in the portage rsync tree, if
	configured it will also check the website for new GLSAs not yet in the tree
2.) it will check which GLSAs are not applied to the system (I suggest using a 
	status file for that to allow things like --inject and to improve performance)
3.) now it does the same syntax and semantic checks	as the posting script and it
	verifies the gpg signature (where do we get the public keys? keyservers, 
	rsync tree, http?)
4.) when the GLSA is ok it will test if the system is affected by the GLSA, if yes
	it will execute the actions defined in the GLSA (usually a package update,
	but other actions can be defined too).
	
This is the actual update process. The current prototype of the update tool has
some other possibilities like displaying a plaintext version of the GLSA or 
manipulating the status file, but currently lacks GPG support and only has
some very basic checks.