1 |
robbat2 10/01/31 07:53:30 |
2 |
|
3 |
Modified: glep-0058.txt |
4 |
Log: |
5 |
Revise GLEP58 per Calchan questions: Additional levels of Manifests are no longer optional; Clarifications added to creation process; |
6 |
|
7 |
Revision Changes Path |
8 |
1.7 xml/htdocs/proj/en/glep/glep-0058.txt |
9 |
|
10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0058.txt?rev=1.7&view=markup |
11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0058.txt?rev=1.7&content-type=text/plain |
12 |
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0058.txt?r1=1.6&r2=1.7 |
13 |
|
14 |
Index: glep-0058.txt |
15 |
=================================================================== |
16 |
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/glep/glep-0058.txt,v |
17 |
retrieving revision 1.6 |
18 |
retrieving revision 1.7 |
19 |
diff -p -w -b -B -u -u -r1.6 -r1.7 |
20 |
--- glep-0058.txt 13 Jan 2010 03:26:53 -0000 1.6 |
21 |
+++ glep-0058.txt 31 Jan 2010 07:53:30 -0000 1.7 |
22 |
@@ -1,7 +1,7 @@ |
23 |
GLEP: 58 |
24 |
Title: Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest |
25 |
-Version: $Revision: 1.6 $ |
26 |
-Last-Modified: $Date: 2010/01/13 03:26:53 $ |
27 |
+Version: $Revision: 1.7 $ |
28 |
+Last-Modified: $Date: 2010/01/31 07:53:30 $ |
29 |
Author: Robin Hugh Johnson <robbat2@g.o>, |
30 |
Status: Draft |
31 |
Type: Standards Track |
32 |
@@ -9,7 +9,7 @@ Content-Type: text/x-rst |
33 |
Requires: 44, 60 |
34 |
Created: October 2006 |
35 |
Updated: November 2007, June 2008, July 2008, October 2008, January 2010 |
36 |
-Post-History: December 2009 |
37 |
+Post-History: December 2009, January 2010 |
38 |
|
39 |
======== |
40 |
Abstract |
41 |
@@ -75,19 +75,27 @@ located at the root of a repository. |
42 |
--------------------------------------------- |
43 |
Procedure for creating the MetaManifest file: |
44 |
--------------------------------------------- |
45 |
+Summary: |
46 |
+======== |
47 |
+The objective of creating the MetaManifest file(s) is to ensure that |
48 |
+every single file in the tree occurs in at least one Manifest. |
49 |
+ |
50 |
+Process: |
51 |
+======== |
52 |
1. Start at the root of the Gentoo Portage tree (gentoo-x86, although |
53 |
this procedure applies to overlays as well). |
54 |
|
55 |
2. Initialize two unordered sets: COVERED, ALL. |
56 |
|
57 |
- 1. 'ALL' will contain every file in the tree. |
58 |
- 2. 'COVERED' will contain every file that is mentioned in an existing |
59 |
- Manifest2. |
60 |
+ 1. 'ALL' shall contain every file that exists in the present tree. |
61 |
+ 2. 'COVERED' shall contain EVERY file that is mentioned in an existing |
62 |
+ Manifest2. If a file is mentioned in a Manifest2, but does not |
63 |
+ exist, it must still be included. No files should be excluded. |
64 |
|
65 |
3. Traverse the tree, depth-first. |
66 |
|
67 |
1. At the top level only, ignore the following directories: distfiles, |
68 |
- packages, local |
69 |
+ packages, local. |
70 |
2. If a directory contains a Manifest file, extract all relevant local |
71 |
files from it (presently: AUX, MISC, EBUILD; but should follow the |
72 |
evolution of Manifest2 entry types per [#GLEP60]), and place them |
73 |
@@ -121,21 +129,25 @@ Procedure for creating the MetaManifest |
74 |
should not be on the same keyring as developer keys. See [#GLEPxx+3 |
75 |
for further notes]. |
76 |
|
77 |
+Notes: |
78 |
+====== |
79 |
The above does not conflict the proposal contained in GLEP33, which |
80 |
restructure eclasses to include subdirectories and Manifest files, as |
81 |
the Manifest rules above still provide indirect verification for all |
82 |
files after the GLEP33 restructuring if it comes to pass. |
83 |
|
84 |
-If other Manifests are added (such as per-category, per first-level |
85 |
-directory, or protecting versioned eclasses), the size of the |
86 |
-MetaManifest will be greatly reduced, and this specification was written |
87 |
-with such a possible future addition in mind. |
88 |
+Additional levels of Manifests are required, such as per-category, and |
89 |
+in the eclasses, profiles and metadata directories. This ensures that a |
90 |
+change to a singular file causes the smallest possible overall change in |
91 |
+the Manifests as propagated. Creation of the additional levels of |
92 |
+Manifests uses the same process as described above, simply starting at a |
93 |
+different root point. |
94 |
|
95 |
MetaManifest generation will take place as part of the existing process |
96 |
by infrastructure that takes the contents of CVS and prepares it for |
97 |
distribution via rsync, which includes generating metadata. In-tree |
98 |
-Manifest files are not checked at this point, as they are assumed to be |
99 |
-correct. |
100 |
+Manifest files are not validated at this point, as they are assumed to |
101 |
+be correct. |
102 |
|
103 |
-------------------------------------------------------- |
104 |
Verification of one or more items from the MetaManifest: |
105 |
@@ -208,6 +220,14 @@ commit as they do presently, and the Met |
106 |
Infrastructure during the tree generation process, and distributed to |
107 |
users. |
108 |
|
109 |
+Any scripts generating Manifests and the MetaManifest may find it useful |
110 |
+to generate multiple levels of Manifests in parallel, and this is |
111 |
+explicitly permitted, provided that every file in the tree is covered by |
112 |
+at least one Manifest or the MetaManifest file. The uppermost |
113 |
+Manifest (MetaManifest) is the only item that does not occur in any |
114 |
+other Manifest file, but is instead GPG-signed to enable it's |
115 |
+validation. |
116 |
+ |
117 |
-------------------------------------------- |
118 |
MetaManifest and the new Manifest2 filetypes |
119 |
-------------------------------------------- |
120 |
@@ -247,11 +267,11 @@ MetaManifest size considerations |
121 |
With only two levels of Manifests (per-package and top-level), every |
122 |
rsync will cause a lot of traffic transferring the modified top-level |
123 |
MetaManifest. To reduce this, first-level directory Manifests are |
124 |
-strongly recommended. Alternatively, if the distribution method |
125 |
-efficiently handles small patch-like changes in an existing file, |
126 |
-using an uncompressed MetaManifest may be acceptable (this would |
127 |
-primarily be distributed version control systems). Other suggestions |
128 |
-in reducing this traffic are welcomed. |
129 |
+required. Alternatively, if the distribution method efficiently handles |
130 |
+small patch-like changes in an existing file, using an uncompressed |
131 |
+MetaManifest may be acceptable (this would primarily be distributed |
132 |
+version control systems). Other suggestions in reducing this traffic are |
133 |
+welcomed. |
134 |
|
135 |
======================= |
136 |
Backwards Compatibility |