Gentoo Archives: gentoo-dev

From: Marius Mauch <genone@g.o>
To: gentoo-dev@g.o
Cc: security@g.o
Subject: [gentoo-dev] GLEP 14 follow-up / security project
Date: Tue, 23 Sep 2003 04:58:37
1 Hi all,
3 as GLEP 14 has been accepted yesterday I made a little writeup that
4 deals with the upcoming security project and the handling of security
5 bugs. Some of the points mentioned here have been touched in
6 #gentoo-security, this is basically a follow-up of that discussion and
7 the discussion about GLEP 14, as the GLSA release process has to be
8 changed for the final implementation of GLEP 14 (for those joining late:
10 This is just a (not very well thought) proposal, nothing definite. But
11 I'd like to get this off the ground ASAP, as classes start in 3 weeks
12 and will need a lot of time from me then.
14 Basic idea for the handling of security bugs:
16 Security bugs should be kept in bugzilla, but to automate the generation
17 of GLSAs we need a special format somehow, if we use keywords, comments
18 or something different for that is open. To maintain the integrity of
19 that format the direct editing of these bugs should be limited to a few
20 people if possible.
21 The actual filing and editing of these bugs should be done with a new
22 interface that is specially designed for security bugs and GLSA
23 information. Once a security bug is marked as fixed a GLSA generation
24 script is run that generates the GLSA, GPG-signs it (depending on
25 policy) and distributes it on mailing lists, http- and rsync-servers.
26 The update script then can take the GLSAs from /usr/portage/glsa or the
27 http repository (to avoid unneeded syncs just to get the GLSA).
29 course of action:
30 - form the security project and find a lead
31 - define the terms of reference for the security team
32 - specify the format of a GLSA / finalize the DTD
33 - define a policy for GLSAs
34 - write a project website, including policy
35 - define a special format for security bugs that allows script based
36 parsing
37 - code necessary extensions for bugzilla / edit bugzilla config to
38 handle security bugs different
39 - code an interface to bugzilla for entering security bugs using the
40 defined format
41 - code the GLSA generation script
42 - finish the update script and include it in portage/gentoolkit or a new
43 package
44 - (update old GLSAs)
46 special bugzilla handling for security bugs:
47 - only allow a few people to file/close/edit them directly (to maintain
48 the special format) if possible
49 - run the generation script when a security bug is marked as fixed
50 (maybe define other actions for other resolutions ??)
52 needed tools:
53 - bugzilla extension ??
54 - GLSA generation script which does:
55 * convert the bugzilla/mysql data to plaintext and XML
56 * signs the GLSA (details depend on policy)
57 * sends the GLSA to a set of defined mailinglist
58 * commits the GLSA into a repository from where it is uploaded/copied
59 to the gentoo-x86 tree and the project website repository (for online
60 checking)
61 * sends a notice to the forum moderators (or post directly ??)
62 - update script (which can be integrated into portage later), mostly
63 done
64 - bugzilla interface site
66 idea for GLSA policy:
67 - everyone who should be able to issue a GLSA needs a GPG key that is
68 signed by a master security project key
69 - the GLSA is signed with the master security project key and the key of
70 the developer who closed the bug
71 - before a bug is closed at least one other security project member has
72 to confirm it
74 I'm sure I missed a lot of things but I think the general idea should be
75 clear. Everything is open for discussion.
76 So, what do you think about this?
78 Marius
80 --
81 Public Key at
83 In the beginning, there was nothing. And God said, 'Let there be
84 Light.' And there was still nothing, but you could see a bit better.


Subject Author
Re: [gentoo-dev] GLEP 14 follow-up / security project Grant Goodyear <g2boojum@g.o>
Re: [gentoo-dev] GLEP 14 follow-up / security project Matt Thrailkill <xwred1@×××××××××.net>