en/glep/glep-0014.txt

GLEP: 14
Title: security updates based on GLSA
Version: $Revision: 1.5 $
Last-Modified: $Date: 2004/10/26 00:21:28 $
Author: Marius Mauch <genone@genone.de>,
Status: Accepted
Type: Standards Track
Content-Type: text/x-rst
Created: 18 Aug 2003
Post-History: 22-Aug-2003, 24-Aug-2003, 10-Nov-2003, 25-Oct-2004
Requires: 21

Abstract
========

There is currently no automatic way to check a Gentoo system for identified
security holes or auto-apply security fixes. This GLEP proposes a way to deal
with this issue

Status Update
=============

Preliminary implementation ``glsa-check`` in gentoolkit, final implementation 
pending set support in portage (GLEP 21).


Motivation
==========

Automatic checking for security updates is a often requested feature for Gentoo.
Implementing it will enable users to fix security holes without reading every
security announcement. It's also a feature that is often required in enterprise
environments.


Proposed change
===============

Update tool
-----------

The coding part of this GLEP is a update tool that reads a GLSA, verifies its
GPG signature, checks if the system is affected by it and executes one of the 
following actions, depending on user preferences:

- run all steps necessary to fix the security hole, including package updates and
  daemon restarts.
- instruct the user how to fix the security hole.
- print the GLSA so the user can get more information if desired.

Once this tool is implemented and well tested it can be integrated into portage.
A prototype `implementation`_ for this tool exists.


GLSA format
-----------

The GLSA format needs to be specified, I suggest using XML for that to simplify
parsing and later extensions. See `implementation`_ for a sample DTD. The format
has to be compatible with the update tool of course. If necessary a converter
tool or an editor could be written for people not comfortable with XML (update:
a QT based editor for the GLSA format written by plasmaroo exists in the 
gentoo-projects repository). Every GLSA has to be GPG signed by the responsible 
developer, who has to be a member of the security herd.


GLSA release process
--------------------

Additional to sending the GLSA to the gentoo-announce mailing list it has to be
stored on a HTTP/FTP server and in the portage tree. I'd suggest a script should 
be used to release a GLSA that will:

- check the GLSA for correctness
- sign the GLSA with the developers GPG key
- send a mail to gentoo-announce with the XML GLSA and a plaintext version attached
- upload it to www.gentoo.org/security/en/glsa (via cvs commit)
- put it on the rsync server (via cvs commit)
- notify the moderators on the forums to make an announcement


Portage changes
---------------

Until the `update tool`_ is integrated into portage there will be no code changes
to portage. The update tool might require a few new configuration options, these
could be placed in make.conf or another config file in /etc/portage.


Rationale
=========

The lack of automated security updates for Gentoo is one of the most often requested
features for portage as it is one of the standard features of other distributions.
As Gentoo already provides GLSAs for important security bugs it is only natural
to use these to implement this feature.

To parse a GLSA in a program the format needs to be specified and a parser has
to be written. I suggest the use of XML for future GLSAs for the following reasons:

- can be parsed and validated with existing libraries
- easy to extend while maintaining backwards compatibility
- tools can convert XML GLSAs in other formats, the other direction would be harder
- websites can use XSLT to markup GLSAs

Putting the GLSAs in the portage tree allows all users to check their systems
for security updates without taking more actions and simplifies later integration
of the update tool into portage. For security minded persons the GLSAs are 
available on a HTTP server to ease the load of the rsync servers.

To verify the signatures of the GLSAs the public keys of the developers should be
available in the portage tree and on the HTTP server. The verification is necessary
to prevent exploits by fake GLSAs.


Implementation
==============

A prototype implementation (including the update tool, a DTD and a sample
XMLified GLSA) exists at http://gentoo.devel-net.org/glsa/ and in the 
gentoo-projects/gentoo-security/GLSA repository. This GLEP is based 
on that implementation, though it can be changed or rewritten if necessary.


Backwards compatibility
=======================

The current `GLSA release process`_ needs to be replaced with this proposal. It 
would be nice if old GLSAs would be transformed into XML as well, but that is
not a requirement for this GLEP.


Copyright
=========

This document has been placed in the public domain.
1	g2boojum	1.1	GLEP: 14
2			Title: security updates based on GLSA
3	genone	1.6	Version: $Revision: 1.5 $
4			Last-Modified: $Date: 2004/10/26 00:21:28 $
5	g2boojum	1.1	Author: Marius Mauch <genone@genone.de>,
6	g2boojum	1.4	Status: Accepted
7	g2boojum	1.1	Type: Standards Track
8			Content-Type: text/x-rst
9			Created: 18 Aug 2003
10	g2boojum	1.5	Post-History: 22-Aug-2003, 24-Aug-2003, 10-Nov-2003, 25-Oct-2004
11	genone	1.6	Requires: 21
12	g2boojum	1.1
13			Abstract
14			========
15
16			There is currently no automatic way to check a Gentoo system for identified
17			security holes or auto-apply security fixes. This GLEP proposes a way to deal
18			with this issue
19
20	g2boojum	1.5	Status Update
21			=============
22
23	genone	1.6	Preliminary implementation ``glsa-check`` in gentoolkit, final implementation
24			pending set support in portage (GLEP 21).
25	g2boojum	1.5
26	g2boojum	1.1
27			Motivation
28			==========
29
30			Automatic checking for security updates is a often requested feature for Gentoo.
31			Implementing it will enable users to fix security holes without reading every
32			security announcement. It's also a feature that is often required in enterprise
33			environments.
34
35
36			Proposed change
37			===============
38
39			Update tool
40			-----------
41
42	g2boojum	1.3	The coding part of this GLEP is a update tool that reads a GLSA, verifies its
43			GPG signature, checks if the system is affected by it and executes one of the
44			following actions, depending on user preferences:
45	g2boojum	1.1
46			- run all steps necessary to fix the security hole, including package updates and
47			daemon restarts.
48			- instruct the user how to fix the security hole.
49			- print the GLSA so the user can get more information if desired.
50
51			Once this tool is implemented and well tested it can be integrated into portage.
52			A prototype `implementation`_ for this tool exists.
53
54
55			GLSA format
56			-----------
57
58			The GLSA format needs to be specified, I suggest using XML for that to simplify
59			parsing and later extensions. See `implementation`_ for a sample DTD. The format
60			has to be compatible with the update tool of course. If necessary a converter
61	g2boojum	1.4	tool or an editor could be written for people not comfortable with XML (update:
62			a QT based editor for the GLSA format written by plasmaroo exists in the
63			gentoo-projects repository). Every GLSA has to be GPG signed by the responsible
64			developer, who has to be a member of the security herd.
65	g2boojum	1.1
66
67			GLSA release process
68			--------------------
69
70			Additional to sending the GLSA to the gentoo-announce mailing list it has to be
71			stored on a HTTP/FTP server and in the portage tree. I'd suggest a script should
72			be used to release a GLSA that will:
73
74			- check the GLSA for correctness
75	g2boojum	1.3	- sign the GLSA with the developers GPG key
76	g2boojum	1.1	- send a mail to gentoo-announce with the XML GLSA and a plaintext version attached
77	g2boojum	1.4	- upload it to www.gentoo.org/security/en/glsa (via cvs commit)
78			- put it on the rsync server (via cvs commit)
79	g2boojum	1.1	- notify the moderators on the forums to make an announcement
80
81
82			Portage changes
83			---------------
84
85			Until the `update tool`_ is integrated into portage there will be no code changes
86			to portage. The update tool might require a few new configuration options, these
87			could be placed in make.conf or another config file in /etc/portage.
88
89
90			Rationale
91			=========
92
93			The lack of automated security updates for Gentoo is one of the most often requested
94			features for portage as it is one of the standard features of other distributions.
95			As Gentoo already provides GLSAs for important security bugs it is only natural
96			to use these to implement this feature.
97
98			To parse a GLSA in a program the format needs to be specified and a parser has
99			to be written. I suggest the use of XML for future GLSAs for the following reasons:
100
101			- can be parsed and validated with existing libraries
102			- easy to extend while maintaining backwards compatibility
103			- tools can convert XML GLSAs in other formats, the other direction would be harder
104			- websites can use XSLT to markup GLSAs
105
106			Putting the GLSAs in the portage tree allows all users to check their systems
107			for security updates without taking more actions and simplifies later integration
108			of the update tool into portage. For security minded persons the GLSAs are
109			available on a HTTP server to ease the load of the rsync servers.
110	g2boojum	1.3
111			To verify the signatures of the GLSAs the public keys of the developers should be
112			available in the portage tree and on the HTTP server. The verification is necessary
113			to prevent exploits by fake GLSAs.
114	g2boojum	1.1
115
116			Implementation
117			==============
118
119			A prototype implementation (including the update tool, a DTD and a sample
120	g2boojum	1.4	XMLified GLSA) exists at http://gentoo.devel-net.org/glsa/ and in the
121			gentoo-projects/gentoo-security/GLSA repository. This GLEP is based
122	g2boojum	1.1	on that implementation, though it can be changed or rewritten if necessary.
123
124
125			Backwards compatibility
126			=======================
127
128			The current `GLSA release process`_ needs to be replaced with this proposal. It
129			would be nice if old GLSAs would be transformed into XML as well, but that is
130			not a requirement for this GLEP.
131
132
133			Copyright
134			=========
135
136			This document has been placed in the public domain.