Contents of /xml/htdocs/proj/en/glep/glep-0057.html

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.7 - (show annotations) (download) (as text)
Wed Apr 7 21:56:59 2010 UTC (8 years, 11 months ago) by robbat2
Branch: MAIN
Changes since 1.6: +43 -21 lines
File MIME type: text/html
Sync HTML for updated references.

1 <?xml version="1.0" encoding="utf-8" ?>
2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
3 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
5 <head>
6 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
7 <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
8 <title>GLEP 57 -- Security of distribution of Gentoo software - Overview</title>
9 <link rel="stylesheet" href="tools/glep.css" type="text/css" /></head>
10 <body bgcolor="white">
11 <table class="navigation" cellpadding="0" cellspacing="0"
12 width="100%" border="0">
13 <tr><td class="navicon" width="150" height="35">
14 <a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
15 <img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
16 border="0" width="150" height="35" /></a></td>
17 <td class="textlinks" align="left">
18 [<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
19 [<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
20 [<b><a href="http://www.gentoo.org/proj/en/glep/glep-0057.txt">GLEP Source</a></b>]
21 </td></tr></table>
22 <table class="rfc2822 docutils field-list" frame="void" rules="none">
23 <col class="field-name" />
24 <col class="field-body" />
25 <tbody valign="top">
26 <tr class="field"><th class="field-name">GLEP:</th><td class="field-body">57</td>
27 </tr>
28 <tr class="field"><th class="field-name">Title:</th><td class="field-body">Security of distribution of Gentoo software - Overview</td>
29 </tr>
30 <tr class="field"><th class="field-name">Version:</th><td class="field-body">1.6</td>
31 </tr>
32 <tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0057.txt?cvsroot=gentoo">2010/04/07 21:34:24</a></td>
33 </tr>
34 <tr class="field"><th class="field-name">Author:</th><td class="field-body">Robin Hugh Johnson &lt;robbat2&#32;&#97;t&#32;gentoo.org&gt;</td>
35 </tr>
36 <tr class="field"><th class="field-name">Status:</th><td class="field-body">Final</td>
37 </tr>
38 <tr class="field"><th class="field-name">Type:</th><td class="field-body">Informational</td>
39 </tr>
40 <tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference external" href="glep-0002.html">text/x-rst</a></td>
41 </tr>
42 <tr class="field"><th class="field-name">Created:</th><td class="field-body">November 2005</td>
43 </tr>
44 <tr class="field"><th class="field-name">Updated:</th><td class="field-body">May 2006, October 2006, November 2007, June 2008, July 2008, October 2008, January 2010</td>
45 </tr>
46 <tr class="field"><th class="field-name">Post-History:</th><td class="field-body">December 2009</td>
47 </tr>
48 <tr class="field"><th class="field-name">Approved:</th><td class="field-body">18 January 2010</td>
49 </tr>
50 </tbody>
51 </table>
52 <hr />
53 <div class="contents topic" id="contents">
54 <p class="topic-title first">Contents</p>
55 <ul class="simple">
56 <li><a class="reference internal" href="#abstract" id="id1">Abstract</a></li>
57 <li><a class="reference internal" href="#motivation" id="id2">Motivation</a></li>
58 <li><a class="reference internal" href="#specification" id="id3">Specification</a><ul>
59 <li><a class="reference internal" href="#system-elements" id="id4">System Elements</a></li>
60 <li><a class="reference internal" href="#processes" id="id5">Processes</a></li>
61 <li><a class="reference internal" href="#attacks-against-processes" id="id6">Attacks against Processes</a></li>
62 <li><a class="reference internal" href="#security-for-processes" id="id7">Security for Processes</a></li>
63 </ul>
64 </li>
65 <li><a class="reference internal" href="#backwards-compatibility" id="id8">Backwards Compatibility</a></li>
66 <li><a class="reference internal" href="#endnote-history-of-tree-signing-in-gentoo" id="id9">Endnote: History of tree-signing in Gentoo</a></li>
67 <li><a class="reference internal" href="#thanks" id="id10">Thanks</a></li>
68 <li><a class="reference internal" href="#references" id="id11">References</a></li>
69 <li><a class="reference internal" href="#copyright" id="id12">Copyright</a></li>
70 </ul>
71 </div>
72 <div class="section" id="abstract">
73 <h1><a class="toc-backref" href="#id1">Abstract</a></h1>
74 <p>This is the first in a series of 4 GLEPs. It aims to define the actors
75 and problems in the Gentoo software distribution process, with a strong
76 emphasis on security. The concepts thus developed, will then be used in
77 the following GLEPs to describe a comprehensive security solution for
78 this distribution process that prevents trivial attacks and increases
79 the difficulty on more complex attacks.</p>
80 </div>
81 <div class="section" id="motivation">
82 <h1><a class="toc-backref" href="#id2">Motivation</a></h1>
83 <p>Since at mid-2002 (see endnote: &quot;History of tree-signing in Gentoo&quot;),
84 many discussions have taken place on the gentoo-dev mailing list and in
85 many other places to design and implement a security strategy for the
86 distribution of files by the Gentoo project.</p>
87 <p>Usually the goal of such proposals was and is to be able to securely
88 identify the data provided by Gentoo and prevent third parties (like a
89 compromised mirror) from delivering harmful data (be it as modified
90 ebuilds, executable shell code or any other form) to the users of the
91 Gentoo MetaDistribution.</p>
92 <p>These strategies can neither prevent a malicious or compromised upstream
93 from injecting &quot;bad&quot; programs, nor can they stop a rogue developer from
94 committing malicious ebuilds. What they can do is to reduce the attack
95 vectors so that for example a compromised mirror will be detected and no
96 tainted data will be executed on user's systems.</p>
97 <p>Gentoo's software distribution system as it presently stands, contains a
98 number of security shortcomings. The last discussion on the gentoo-dev
99 mailing list [<a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/38363">http://thread.gmane.org/gmane.linux.gentoo.devel/38363</a>]
100 contains a good overview of most of the issues. Summarized here:</p>
101 <blockquote>
102 <ul class="simple">
103 <li>Unverifiable executable code distributed:
104 The most obvious instance are eclasses, but there are many other bits
105 of the tree that are not signed at all right now. Modifying that data
106 is trivial.</li>
107 <li>Shortcomings of existing Manifest verification
108 A lack and enforcement of policies, combined with suboptimal support
109 in portage, makes it trivial to modify or replace the existing
110 Manifests.</li>
111 <li>Vulnerability of existing infrastructure to attacks.
112 The previous two items make it possible for a skilled attacker to
113 design an attack and then execute it against specific portions of
114 existing infrastructure (e.g.: Compromise a country-local rsync
115 mirror, and totally replace a package and it's Manifest).</li>
116 </ul>
117 </blockquote>
118 </div>
119 <div class="section" id="specification">
120 <h1><a class="toc-backref" href="#id3">Specification</a></h1>
121 <p>Security is not something that can be considered in isolation. It is
122 both an ongoing holistic process and lessons learnt by examining
123 previous shortcomings.</p>
124 <div class="section" id="system-elements">
125 <h2><a class="toc-backref" href="#id4">System Elements</a></h2>
126 <dl class="docutils">
127 <dt>There are a few entities to be considered:</dt>
128 <dd><ul class="first last simple">
129 <li>Upstream. The people who provide the program(s) or data we wish to
130 distribute.</li>
131 <li>Gentoo Developers. The people that package and test the things
132 provided by Upstream.</li>
133 <li>Gentoo Infrastructure. The people and hardware that allow the revision
134 control of metadata and distribution of the data and metadata provided
135 by Developers and Upstream.</li>
136 <li>Gentoo Mirrors. Hardware provided by external contributors that is not
137 or only marginally controlled by Gentoo Infrastructure. Needed to
138 achieve the scalability and performance needed for the substantial
139 Gentoo user base.</li>
140 <li>Gentoo Users. The people that use the Gentoo MetaDistribution.</li>
141 </ul>
142 </dd>
143 </dl>
144 <p>The data described here is usually programs and data files provided by
145 upstream; as this is a rather large amount of data it is usually
146 distributed over http or ftp from Gentoo Mirrors. This data is usually
147 labeled as &quot;distfiles&quot;. Metadata is all information describing how to
148 manipulate that data - it is usually called &quot;The Tree&quot; or &quot;The Portage
149 Tree&quot;, consists of many ebuilds, eclasses and supporting files and is
150 usually distributed over rsync. The central rsync servers are controlled
151 by Gentoo Infrastructure, but many third-party rsync mirrors exist that
152 help to reduce the load on those central servers. These extra mirrors
153 are not maintained by Gentoo Infrastructure.</p>
154 <p>Attacks may be conducted against any of these entities. Obviously
155 direct attacks against Upstream and Users are outside of the scope of
156 this series of GLEPs as they are not in any way controlled or
157 controllable by Gentoo - however attacks using Gentoo as a conduit
158 (including malicious mirrors) must be considered.</p>
159 </div>
160 <div class="section" id="processes">
161 <h2><a class="toc-backref" href="#id5">Processes</a></h2>
162 <p>There are two major processes in the distribution of Gentoo, where
163 security needs to be implemented:</p>
164 <blockquote>
165 <ul class="simple">
166 <li>Developer commits to version control systems controlled by
167 Infrastructure.</li>
168 <li>Tree and distfile distribution from Infrastructure to Users, via the
169 mirrors (this includes both HTTP and rsync distribution).</li>
170 </ul>
171 </blockquote>
172 <p>Both processes need their security improved. In [GLEPxx2] we will discuss
173 how to improve the security of the first process. The relatively
174 speaking simpler process of file distribution will be described in
175 [GLEP58]. Since it can be implemented without having to change the
176 workflow and behaviour of developers we hope to get it done in a
177 reasonably short timeframe.</p>
178 </div>
179 <div class="section" id="attacks-against-processes">
180 <h2><a class="toc-backref" href="#id6">Attacks against Processes</a></h2>
181 <p>Attacks against the process #1 may be as complex as a malicious or
182 compromised developer (stolen SSH keys, rooted systems), or as simple as
183 a patch from a user that does a little more than it claims, and is not
184 adequately reviewed.</p>
185 <p>Attacks against the process #2 may be as simple as a single rooted
186 mirror, distributing a modified tree to the users of that mirror - or
187 some alteration of upstream sources. These attacks have a low cost and
188 are very hard to discover unless all distributed data is transparently
189 signed.</p>
190 <p>A simple example of such an attack and a partial solution for eclasses
191 is presented in [ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/24677">http://thread.gmane.org/gmane.linux.gentoo.devel/24677</a>
192 ]. It shows quite well that any non-Gentoo controlled rsync mirror can
193 modify executable code; as much of this code is per default run as root
194 a malicious mirror could compromise hundreds of systems per day - if
195 cloaked well enough, such an attack could run for weeks before being
196 noticed. As there are no effective safeguards right now users are left
197 with the choice of either syncing from the sometimes slow or even
198 unresponsive Gentoo-controlled rsync mirrors or risk being compromised
199 by syncing from one of the community-provided mirrors. We will show that
200 protection against this class of attacks is very easy to implement with
201 little added cost.</p>
202 <p>At the level of mirrors, addition of malicious content is not the only
203 attack. As discussed by Cappos et al [C08a,C08b], an attacker may use
204 exclusion and replay attacks, possibly only on a specific subset of
205 user to extend the window of opportunity on another exploit.</p>
206 </div>
207 <div class="section" id="security-for-processes">
208 <h2><a class="toc-backref" href="#id7">Security for Processes</a></h2>
209 <p>Protection for process #1 can never be complete (without major
210 modifications to our development process), as a malicious developer is
211 fully authorized to provide materials for distribution. Partial
212 protection can be gained by Portage and Infrastructure changes, but the
213 real improvements needed are developer education and continued
214 vigilance. This is further discussed in [GLEPxx2].</p>
215 <p>This security is still limited in scope - protection against compromised
216 developers is very expensive, and even complex systems like peer review
217 / multiple signatures can be broken by colluding developers. There are many
218 issues, be it social or technical, that increase the cost of such
219 measures a lot while only providing marginal security gains. Any
220 implementation proposal must be carefully analysed to find the best
221 security to developer hassle ratio.</p>
222 <p>Protection for process #2 is a different matter entirely. While it also
223 cannot be complete (as the User may be attacked directly), we can ensure
224 that Gentoo infrastructure and the mirrors are not a weak point. This
225 objective is actually much closer than it seems already - most of the
226 work has been completed for other things!. This is further discussed in
227 [GLEP58]. As this process has the most to gain in security, and the
228 most immediate impact, it should be implemented before or at the same
229 time as any changes to process #1. Security at this layer is already
230 available in the signed daily snapshots, but we can extend it to cover
231 the rsync mirrors as well.</p>
232 <p>Requirements pertaining to and management of keys (OpenPGP or otherwise)
233 is an issue that affects both processes, and is broken out into a
234 separate GLEP due to the technical complexity of the subject.
235 This deals with everything including: types of keys to use; usage
236 guidelines; procedures for managing signatures and trust for keys,
237 including cases of lost (destroyed) and stolen (or otherwise turned
238 malicious) keys.</p>
239 </div>
240 </div>
241 <div class="section" id="backwards-compatibility">
242 <h1><a class="toc-backref" href="#id8">Backwards Compatibility</a></h1>
243 <p>As an informational GLEP, this document has no direct impact on
244 backwards compatibility. However the related in-depth documents may
245 delve further into any issues of backwards compatibility.</p>
246 </div>
247 <div class="section" id="endnote-history-of-tree-signing-in-gentoo">
248 <h1><a class="toc-backref" href="#id9">Endnote: History of tree-signing in Gentoo</a></h1>
249 <p>This is a brief review of every previous tree-signing discussion, the
250 stuff before 2003-04-03 was very hard to come by, so I apologize if I've
251 missed a discussion (I would like to hear about it). I think there was
252 a very early private discussion with drobbins in 2001, as it's vaguely
253 referenced, but I can't find it anywhere.</p>
254 <p>2002-06-06, gentoo-dev mailing list, users first ask about signing of
255 ebuilds:
256 [ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/1950">http://thread.gmane.org/gmane.linux.gentoo.devel/1950</a> ]</p>
257 <p>2003-01-13, gentoo-dev mailing list, &quot;Re: Verifying portage is from
258 Gentoo&quot; - Paul de Vrieze (pauldv):
259 [ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/6619/focus=6619">http://thread.gmane.org/gmane.linux.gentoo.devel/6619/focus=6619</a> ]</p>
260 <p>2003-04, GWN articles announcing tree signing:
261 [ <a class="reference external" href="http://www.gentoo.org/news/en/gwn/20030407-newsletter.xml#doc_chap1_sect3">http://www.gentoo.org/news/en/gwn/20030407-newsletter.xml#doc_chap1_sect3</a> ]
262 [ <a class="reference external" href="http://www.gentoo.org/news/en/gwn/20030421-newsletter.xml#doc_chap1_sect2">http://www.gentoo.org/news/en/gwn/20030421-newsletter.xml#doc_chap1_sect2</a> ]</p>
263 <p>2003-04, gentoo-security mailing list, &quot;The state of ebuild signing
264 in portage&quot; - Joshua Brindle (method), the first suggestion of signed Manifests,
265 but also an unusual key-trust model:
266 [ <a class="reference external" href="http://marc.theaimsgroup.com/?l=gentoo-security&amp;m=105073449619892&amp;w=2">http://marc.theaimsgroup.com/?l=gentoo-security&amp;m=105073449619892&amp;w=2</a> ]</p>
267 <p>2003-04, gentoo-core mailing list, &quot;New Digests and Signing -- Attempted Explanation&quot;</p>
268 <p>2003-06, gentoo-core mailing list, &quot;A quick guide to GPG and key
269 signing.&quot; - This overview was one of the first to help developers see
270 how to use their devs, and was mainly intended for keysigning meetups.</p>
271 <p>2003-08-09, gentoo-core mailing list, &quot;Ebuild signing&quot; - status query,
272 with an not very positive response, delayed by Nick Jones (carpaski)
273 getting rooted and a safe cleanup taking a long time to affect.</p>
274 <p>2003-12-02, gentoo-core mailing list, &quot;Report: rsync1.it.gentoo.org compromised&quot;</p>
275 <p>2003-12-03, gentoo-core mailing list, &quot;Signing of ebuilds&quot;</p>
276 <p>2003-12-07, gentoo-core mailing list, &quot;gpg signing of Manifests&quot;, thread
277 includes the first GnuPG signing prototype code, by Robin H. Johnson
278 (robbat2). Andrew Cowie (rac) also produces a proof-of-concept around
279 this time.</p>
280 <p>2004-03-23, gentoo-dev mailing list, &quot;2004.1 will not include a secure
281 portage&quot; - Kurt Lieber (klieber). Signing is nowhere near ready for
282 2004.1 release, and it is realized that it there is insufficient traction
283 and the problem is very large. Many arguments about the checking and
284 verification side. First warning signs that MD5 might be broken in the
285 near future.
286 [ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/16876">http://thread.gmane.org/gmane.linux.gentoo.devel/16876</a> ]</p>
287 <p>2004-03-25, gentoo-dev mailing list, &quot;Redux: 2004.1 will not include a
288 secure portage&quot; - Robin H. Johnson (robbat2). Yet another proposal,
289 summarizing the points of the previous thread and this time trying to
290 track the various weaknesses.
291 <a class="reference external" href="http://marc.theaimsgroup.com/?l=gentoo-dev&amp;m=108017986400698&amp;w=2">http://marc.theaimsgroup.com/?l=gentoo-dev&amp;m=108017986400698&amp;w=2</a></p>
292 <p>2004-05-31, Gentoo managers meeting, portage team reports that
293 FEATURES=sign is now available, but large questions still exist over
294 verification policies and procedures, as well as handing of keys.
295 [ <a class="reference external" href="http://www.gentoo.org/proj/en/devrel/manager-meetings/logs/2004/20040531.txt">http://www.gentoo.org/proj/en/devrel/manager-meetings/logs/2004/20040531.txt</a> ]</p>
296 <p>2005-01-17, gentoo-core mailing list, &quot;Global objective for 2005 :
297 portage signing&quot;. Thierry Carrez (koon) suggests that more go into
298 tree-signing work. Problems at the time later in the thread show that
299 the upstream gpg-agent is not ready, amongst other minor implementation
300 issues.</p>
301 <p>2005-02-20, gentoo-dev mailing list, &quot;post-LWE 2005&quot; - Brian Harring
302 (ferringb). A discussion on the ongoing lack of signing, and that
303 eclasses and profiles need to be signed as well, but this seems to be
304 hanging on GLEP33 in the meantime.
305 [ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/25556/focus=25596">http://thread.gmane.org/gmane.linux.gentoo.devel/25556/focus=25596</a> ]</p>
306 <p>2005-03-08, gentoo-core mailing list, &quot;gpg manifest signing stats&quot;.
307 Informal statistics show that 26% of packages in the tree include a
308 signed Manifest. Questions are raised regarding key types, and key
309 policies.</p>
310 <p>2005-11-16, gentoo-core mailing list, &quot;Gentoo key signing practices and
311 official Gentoo keyring&quot;. A discussion of key handling and other
312 outstanding issues, also mentioning partial Manifests, as well as a
313 comparision between the signing procedures used in Slackware, Debian and
314 RPM-based distros.</p>
315 <p>2005-11-19, gentoo-portage-dev mailing list, &quot;Manifest signing&quot; - Robin
316 H. Johnson (robbat2) follows up the previous -core posting, discussion
317 implementation issues.
318 [ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1401">http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1401</a> ]</p>
319 <p>2006-05-18, gentoo-dev mailing list, &quot;Signing everything, for fun and for
320 profit&quot; - Patrick Lauer (bonsaikitten). Later brings up that Manifest2 is needed for
321 getting everything right.
322 [ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/38363">http://thread.gmane.org/gmane.linux.gentoo.devel/38363</a> ]</p>
323 <p>2006-05-19, gentoo-dev mailing list, &quot;Re: Signing everything, for fun and for
324 profit&quot; - Robin H. Johnson (robbat2). An introduction into some of the
325 OpenPGP standard, with a focus on how it affects file signing, key
326 signing, management of keys, and revocation.
327 [ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/38363/focus=38371">http://thread.gmane.org/gmane.linux.gentoo.devel/38363/focus=38371</a> ]</p>
328 <p>2007-04-11, gentoo-dev mailing list, &quot;Re: <em>DEVELOPMENT</em> mail list,
329 right?&quot; - Robin H. Johnson (robbat2). A progress report on these very
330 GLEPs.
331 [ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/47752/focus=47908">http://thread.gmane.org/gmane.linux.gentoo.devel/47752/focus=47908</a> ]</p>
332 <p>2007-07-02, gentoo-dev mailing list, &quot;Re: Re: Nominations open for the
333 Gentoo Council 2007/08&quot; - Robin H. Johnson (robbat2). Another progress
334 report.
335 [ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/50029/focus=50043">http://thread.gmane.org/gmane.linux.gentoo.devel/50029/focus=50043</a> ]</p>
336 <p>2007-11-30, portage-dev alias, &quot;Manifest2 and Tree-signing&quot; - Robin H.
337 Johnson (robbat2). First review thread for these GLEPs, many suggestions
338 from Marius Mauch (genone).</p>
339 <p>2008-04-03, gentoo-dev mailing list, &quot;Re: Monthly Gentoo Council
340 Reminder for April&quot; - Ciaran McCreesh (ciaranm). A thread in which
341 Ciaran reminds everybody that simply making all the developers sign the
342 tree is not sufficient to prevent all attacks.
343 [ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.devel/55508/focus=55542">http://thread.gmane.org/gmane.linux.gentoo.devel/55508/focus=55542</a> ]</p>
344 <p>2008-07-01, gentoo-portage-dev mailing list, &quot;proto-GLEPS for
345 Tree-signing&quot; - Robin H. Johnson (robbat2). Thread looking for review
346 input from Portage developers.
347 [ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2686">http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2686</a> ]</p>
348 <p>2008-07-12, gentoo-portage-dev mailing list, &quot;proto-GLEPS for
349 Tree-signing, take 2&quot; - Robin H. Johnson (robbat2). Integration of
350 changes from previous review, and a prototype for the signing code.
351 zmedico also posts a patch for a verification prototype.
352 [ <a class="reference external" href="http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2709">http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2709</a> ]</p>
353 </div>
354 <div class="section" id="thanks">
355 <h1><a class="toc-backref" href="#id10">Thanks</a></h1>
356 <p>I'd like to thank Patrick Lauer (bonsaikitten) for prodding me
357 to keep working on the tree-signing project, as well helping with
358 spelling, grammar, research (esp. tracking down every possible
359 vulnerability that has been mentioned in past discussions, and
360 integrating them in this overview).</p>
361 </div>
362 <div class="section" id="references">
363 <h1><a class="toc-backref" href="#id11">References</a></h1>
364 <table class="docutils citation" frame="void" id="c08a" rules="none">
365 <colgroup><col class="label" /><col /></colgroup>
366 <tbody valign="top">
367 <tr><td class="label">[C08a]</td><td>Cappos, J et al. (2008). &quot;Package Management Security&quot;.
368 University of Arizona Technical Report TR08-02. Available online
369 from: <a class="reference external" href="ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf">ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf</a></td></tr>
370 </tbody>
371 </table>
372 <table class="docutils citation" frame="void" id="c08b" rules="none">
373 <colgroup><col class="label" /><col /></colgroup>
374 <tbody valign="top">
375 <tr><td class="label">[C08b]</td><td>Cappos, J et al. (2008). &quot;Attacks on Package Managers&quot;
376 Available online at:
377 <a class="reference external" href="http://www.cs.arizona.edu/people/justin/packagemanagersecurity/">http://www.cs.arizona.edu/people/justin/packagemanagersecurity/</a></td></tr>
378 </tbody>
379 </table>
380 <table class="docutils citation" frame="void" id="glep58" rules="none">
381 <colgroup><col class="label" /><col /></colgroup>
382 <tbody valign="top">
383 <tr><td class="label">[GLEP58]</td><td>Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest
384 <a class="reference external" href="http://www.gentoo.org/proj/en/glep/glep-0058.html">http://www.gentoo.org/proj/en/glep/glep-0058.html</a></td></tr>
385 </tbody>
386 </table>
387 <table class="docutils citation" frame="void" id="glepxx2" rules="none">
388 <colgroup><col class="label" /><col /></colgroup>
389 <tbody valign="top">
390 <tr><td class="label">[GLEPxx2]</td><td>Future GLEP on Developer Process security.</td></tr>
391 </tbody>
392 </table>
393 <table class="docutils citation" frame="void" id="glepxx3" rules="none">
394 <colgroup><col class="label" /><col /></colgroup>
395 <tbody valign="top">
396 <tr><td class="label">[GLEPxx3]</td><td>Future GLEP on GnuPG Policies and Handling.</td></tr>
397 </tbody>
398 </table>
399 </div>
400 <div class="section" id="copyright">
401 <h1><a class="toc-backref" href="#id12">Copyright</a></h1>
402 <p>Copyright (c) 2005-2010 by Robin Hugh Johnson. This material may be
403 distributed only subject to the terms and conditions set forth in the
404 Open Publication License, v1.0.</p>
405 <!-- vim: tw=72 ts=2 expandtab: -->
406 </div>
408 </div>
409 <div class="footer">
410 <hr class="footer" />
411 <a class="reference external" href="glep-0057.txt">View document source</a>.
412 Generated on: 2010-04-07 21:54 UTC.
413 Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
415 </div>
416 </body>
417 </html>

  ViewVC Help
Powered by ViewVC 1.1.20