en/glep/glep-0014.txt

GLEP: 14
Title: security updates based on GLSA
Version: $Revision: 1.1 $
Last-Modified: $Date: 2003/08/22 15:00:55 $
Author: Marius Mauch <genone@genone.de>,
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 18 Aug 2003
Post-History: 22-Aug-2003


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


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, 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.


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
- send a mail to gentoo-announce with the XML GLSA and a plaintext version attached
- upload it to www.gentoo.org/glsa (or wherever they should be uploaded)
- put it on the rsync server
- 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.


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

A prototype implementation (including the update tool, a DTD and a sample
XMLified GLSA) exists at http://gentoo.devel-net.org/glsa/ . This GLEP is based 
on that implementation, though it can be changed or rewritten if necessary.
According to portage developers there is also already some support for this in
portage.


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