/[gentoo]/xml/htdocs/proj/en/glep/glep-0014.txt
Gentoo

Contents of /xml/htdocs/proj/en/glep/glep-0014.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.3 - (hide annotations) (download)
Sun Aug 24 22:11:46 2003 UTC (11 years, 1 month ago) by g2boojum
Branch: MAIN
Changes since 1.2: +13 -6 lines
File MIME type: text/plain
Updated gleps.

1 g2boojum 1.1 GLEP: 14
2     Title: security updates based on GLSA
3 g2boojum 1.3 Version: $Revision: $
4     Last-Modified: $Date: $
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.3 Post-History: 22-Aug-2003, 24-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 g2boojum 1.3 The coding part of this GLEP is a update tool that reads a GLSA, verifies its
37     GPG signature, checks if the system is affected by it and executes one of the
38     following actions, depending on user preferences:
39 g2boojum 1.1
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 g2boojum 1.3 Every GLSA has to be GPG signed by the responsible developer, who has to be
57     a member of the security herd.
58 g2boojum 1.1
59    
60     GLSA release process
61     --------------------
62    
63     Additional to sending the GLSA to the gentoo-announce mailing list it has to be
64     stored on a HTTP/FTP server and in the portage tree. I'd suggest a script should
65     be used to release a GLSA that will:
66    
67     - check the GLSA for correctness
68 g2boojum 1.3 - sign the GLSA with the developers GPG key
69 g2boojum 1.1 - send a mail to gentoo-announce with the XML GLSA and a plaintext version attached
70     - upload it to www.gentoo.org/glsa (or wherever they should be uploaded)
71     - put it on the rsync server
72     - notify the moderators on the forums to make an announcement
73    
74    
75     Portage changes
76     ---------------
77    
78     Until the `update tool`_ is integrated into portage there will be no code changes
79     to portage. The update tool might require a few new configuration options, these
80     could be placed in make.conf or another config file in /etc/portage.
81    
82    
83     Rationale
84     =========
85    
86     The lack of automated security updates for Gentoo is one of the most often requested
87     features for portage as it is one of the standard features of other distributions.
88     As Gentoo already provides GLSAs for important security bugs it is only natural
89     to use these to implement this feature.
90    
91     To parse a GLSA in a program the format needs to be specified and a parser has
92     to be written. I suggest the use of XML for future GLSAs for the following reasons:
93    
94     - can be parsed and validated with existing libraries
95     - easy to extend while maintaining backwards compatibility
96     - tools can convert XML GLSAs in other formats, the other direction would be harder
97     - websites can use XSLT to markup GLSAs
98    
99     Putting the GLSAs in the portage tree allows all users to check their systems
100     for security updates without taking more actions and simplifies later integration
101     of the update tool into portage. For security minded persons the GLSAs are
102     available on a HTTP server to ease the load of the rsync servers.
103 g2boojum 1.3
104     To verify the signatures of the GLSAs the public keys of the developers should be
105     available in the portage tree and on the HTTP server. The verification is necessary
106     to prevent exploits by fake GLSAs.
107 g2boojum 1.1
108    
109     Implementation
110     ==============
111    
112     A prototype implementation (including the update tool, a DTD and a sample
113     XMLified GLSA) exists at http://gentoo.devel-net.org/glsa/ . This GLEP is based
114     on that implementation, though it can be changed or rewritten if necessary.
115     According to portage developers there is also already some support for this in
116     portage.
117    
118    
119     Backwards compatibility
120     =======================
121    
122     The current `GLSA release process`_ needs to be replaced with this proposal. It
123     would be nice if old GLSAs would be transformed into XML as well, but that is
124     not a requirement for this GLEP.
125    
126    
127     Copyright
128     =========
129    
130     This document has been placed in the public domain.

  ViewVC Help
Powered by ViewVC 1.1.20