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

Diff of /xml/htdocs/proj/en/glep/glep-0058.txt

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

Revision 1.6 Revision 1.9
1GLEP: 58 1GLEP: 58
2Title: Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest 2Title: Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest
3Version: $Revision: 1.6 $ 3Version: $Revision: 1.9 $
4Last-Modified: $Date: 2010/01/13 03:26:53 $ 4Last-Modified: $Date: 2010/04/07 06:35:16 $
5Author: Robin Hugh Johnson <robbat2@gentoo.org>, 5Author: Robin Hugh Johnson <robbat2@gentoo.org>,
6Status: Draft 6Status: Draft
7Type: Standards Track 7Type: Standards Track
8Content-Type: text/x-rst 8Content-Type: text/x-rst
9Requires: 44, 60 9Requires: 44, 60
10Created: October 2006 10Created: October 2006
11Updated: November 2007, June 2008, July 2008, October 2008, January 2010 11Updated: November 2007, June 2008, July 2008, October 2008, January 2010
12Post-History: December 2009 12Post-History: December 2009, January 2010
13 13
14======== 14========
15Abstract 15Abstract
16======== 16========
17MetaManifest provides a means of verifiable distribution from Gentoo 17MetaManifest provides a means of verifiable distribution from Gentoo
… …
73located at the root of a repository. 73located at the root of a repository.
74 74
75--------------------------------------------- 75---------------------------------------------
76Procedure for creating the MetaManifest file: 76Procedure for creating the MetaManifest file:
77--------------------------------------------- 77---------------------------------------------
78Summary:
79========
80The objective of creating the MetaManifest file(s) is to ensure that
81every single file in the tree occurs in at least one Manifest.
82
83Process:
84========
781. Start at the root of the Gentoo Portage tree (gentoo-x86, although 851. Start at the root of the Gentoo Portage tree (gentoo-x86, although
79 this procedure applies to overlays as well). 86 this procedure applies to overlays as well).
80 87
812. Initialize two unordered sets: COVERED, ALL. 882. Initialize two unordered sets: COVERED, ALL.
82 89
83 1. 'ALL' will contain every file in the tree. 90 1. 'ALL' shall contain every file that exists in the present tree.
84 2. 'COVERED' will contain every file that is mentioned in an existing 91 2. 'COVERED' shall contain EVERY file that is mentioned in an existing
85 Manifest2. 92 Manifest2. If a file is mentioned in a Manifest2, but does not
93 exist, it must still be included. No files should be excluded.
86 94
873. Traverse the tree, depth-first. 953. Traverse the tree, depth-first.
88 96
89 1. At the top level only, ignore the following directories: distfiles, 97 1. At the top level only, ignore the following directories: distfiles,
90 packages, local 98 packages, local.
91 2. If a directory contains a Manifest file, extract all relevant local 99 2. If a directory contains a Manifest file, extract all relevant local
92 files from it (presently: AUX, MISC, EBUILD; but should follow the 100 files from it (presently: AUX, MISC, EBUILD; but should follow the
93 evolution of Manifest2 entry types per [#GLEP60]), and place them 101 evolution of Manifest2 entry types per [#GLEP60]), and place them
94 into the COVERED set. 102 into the COVERED set.
95 3. Recursively add every file in the directory to the ALL set, 103 3. Recursively add every file in the directory to the ALL set,
… …
1168. The MetaManifest must ultimately be GnuPG-signed. 1248. The MetaManifest must ultimately be GnuPG-signed.
117 125
118 1. For the initial implementation, the same key as used for snapshot 126 1. For the initial implementation, the same key as used for snapshot
119 tarball signing is sufficient. 127 tarball signing is sufficient.
120 2. For the future, the key used for fully automated signing by infra 128 2. For the future, the key used for fully automated signing by infra
121 should not be on the same keyring as developer keys. See [#GLEPxx+3 129 should not be on the same keyring as developer keys. See
122 for further notes]. 130 [#GLEPxx+3] for further notes.
123 131
132Notes:
133======
124The above does not conflict the proposal contained in GLEP33, which 134The above does not conflict the proposal contained in GLEP33, which
125restructure eclasses to include subdirectories and Manifest files, as 135restructure eclasses to include subdirectories and Manifest files, as
126the Manifest rules above still provide indirect verification for all 136the Manifest rules above still provide indirect verification for all
127files after the GLEP33 restructuring if it comes to pass. 137files after the GLEP33 restructuring if it comes to pass.
128 138
129If other Manifests are added (such as per-category, per first-level 139Additional levels of Manifests are required, such as per-category, and
130directory, or protecting versioned eclasses), the size of the 140in the eclasses, profiles and metadata directories. This ensures that a
131MetaManifest will be greatly reduced, and this specification was written 141change to a singular file causes the smallest possible overall change in
132with such a possible future addition in mind. 142the Manifests as propagated. Creation of the additional levels of
143Manifests uses the same process as described above, simply starting at a
144different root point.
133 145
134MetaManifest generation will take place as part of the existing process 146MetaManifest generation will take place as part of the existing process
135by infrastructure that takes the contents of CVS and prepares it for 147by infrastructure that takes the contents of CVS and prepares it for
136distribution via rsync, which includes generating metadata. In-tree 148distribution via rsync, which includes generating metadata. In-tree
137Manifest files are not checked at this point, as they are assumed to be 149Manifest files are not validated at this point, as they are assumed to
138correct. 150be correct.
139 151
140-------------------------------------------------------- 152--------------------------------------------------------
141Verification of one or more items from the MetaManifest: 153Verification of one or more items from the MetaManifest:
142-------------------------------------------------------- 154--------------------------------------------------------
143There are two times that this may happen: firstly, immediately after the 155There are two times that this may happen: firstly, immediately after the
… …
206the individual Gentoo developers. They will continue to develop and 218the individual Gentoo developers. They will continue to develop and
207commit as they do presently, and the MetaManifest is added by 219commit as they do presently, and the MetaManifest is added by
208Infrastructure during the tree generation process, and distributed to 220Infrastructure during the tree generation process, and distributed to
209users. 221users.
210 222
223Any scripts generating Manifests and the MetaManifest may find it useful
224to generate multiple levels of Manifests in parallel, and this is
225explicitly permitted, provided that every file in the tree is covered by
226at least one Manifest or the MetaManifest file. The uppermost
227Manifest (MetaManifest) is the only item that does not occur in any
228other Manifest file, but is instead GPG-signed to enable it's
229validation.
230
211-------------------------------------------- 231--------------------------------------------
212MetaManifest and the new Manifest2 filetypes 232MetaManifest and the new Manifest2 filetypes
213-------------------------------------------- 233--------------------------------------------
214While [#GLEP60] describes the addition of new filetypes, these are NOT 234While [#GLEP60] describes the addition of new filetypes, these are NOT
215needed for implementation of the MetaManifest proposal. Without the new 235needed for implementation of the MetaManifest proposal. Without the new
… …
245MetaManifest size considerations 265MetaManifest size considerations
246-------------------------------- 266--------------------------------
247With only two levels of Manifests (per-package and top-level), every 267With only two levels of Manifests (per-package and top-level), every
248rsync will cause a lot of traffic transferring the modified top-level 268rsync will cause a lot of traffic transferring the modified top-level
249MetaManifest. To reduce this, first-level directory Manifests are 269MetaManifest. To reduce this, first-level directory Manifests are
250strongly recommended. Alternatively, if the distribution method 270required. Alternatively, if the distribution method efficiently handles
251efficiently handles small patch-like changes in an existing file, 271small patch-like changes in an existing file, using an uncompressed
252using an uncompressed MetaManifest may be acceptable (this would 272MetaManifest may be acceptable (this would primarily be distributed
253primarily be distributed version control systems). Other suggestions 273version control systems). Other suggestions in reducing this traffic are
254in reducing this traffic are welcomed. 274welcomed.
255 275
256======================= 276=======================
257Backwards Compatibility 277Backwards Compatibility
258======================= 278=======================
259- There are no backwards compatibility issues, as old versions of 279- There are no backwards compatibility issues, as old versions of
… …
276 296
277========== 297==========
278References 298References
279========== 299==========
280 300
281[C08a] Cappos, J et al. (2008). "Package Management Security". 301.. [C08a] Cappos, J et al. (2008). "Package Management Security".
282 University of Arizona Technical Report TR08-02. Available online 302 University of Arizona Technical Report TR08-02. Available online
283 from: ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf 303 from: ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf
304
284[C08b] Cappos, J et al. (2008). "Attacks on Package Managers" 305.. [C08b] Cappos, J et al. (2008). "Attacks on Package Managers"
285 Available online at: 306 Available online at:
286 http://www.cs.arizona.edu/people/justin/packagemanagersecurity/ 307 http://www.cs.arizona.edu/people/justin/packagemanagersecurity/
308
309.. [#GLEPxx+2] Future GLEP on Developer Process security.
310
311.. [#GLEPxx+3] Future GLEP on GnuPG Policies and Handling.
287 312
288========= 313=========
289Copyright 314Copyright
290========= 315=========
291Copyright (c) 2006-2010 by Robin Hugh Johnson. This material may be 316Copyright (c) 2006-2010 by Robin Hugh Johnson. This material may be
Legend:
Removed from v.1.6  
changed lines
  Added in v.1.9
  ViewVC Help
Powered by ViewVC 1.1.17