| 1 |
g2boojum |
1.1 |
GLEP: 14 |
| 2 |
|
|
Title: security updates based on GLSA |
| 3 |
g2boojum |
1.2 |
Version: $Revision: 1.1 $ |
| 4 |
|
|
Last-Modified: $Date: 2003/08/22 15:00:55 $ |
| 5 |
g2boojum |
1.1 |
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 |
g2boojum |
1.2 |
Post-History: 22-Aug-2003 |
| 11 |
g2boojum |
1.1 |
|
| 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. |