--- xml/htdocs/proj/en/glep/glep-0058.html 2010/01/13 03:28:33 1.3 +++ xml/htdocs/proj/en/glep/glep-0058.html 2010/01/31 07:53:41 1.4 @@ -27,9 +27,9 @@
MetaManifest provides a means of verifiable distribution from Gentoo Infrastructure to a user system, while data is conveyed over completely untrusted networks and system, by extending the Manifest2 specification, @@ -85,7 +90,7 @@ Manifests.
As part of a comprehensive security plan, we need a way to prove that something originating from Gentoo as an organization (read Gentoo-owned hardware, run by infrastructure), has not been tampered with. This @@ -114,7 +119,7 @@ by deliberate delay, replay [C08a, C08b] or alteration).
For lack of a better name, the following solution should be known as the MetaManifest. Those responsible for the name have already been sacked.
MetaManifest basically contains hashes of every file in the tree, either @@ -127,19 +132,27 @@
In the following, the MetaManifest file is a file named 'Manifest', located at the root of a repository.
The objective of creating the MetaManifest file(s) is to ensure that +every single file in the tree occurs in at least one Manifest.+
The above does not conflict the proposal contained in GLEP33, which restructure eclasses to include subdirectories and Manifest files, as the Manifest rules above still provide indirect verification for all files after the GLEP33 restructuring if it comes to pass.-
If other Manifests are added (such as per-category, per first-level -directory, or protecting versioned eclasses), the size of the -MetaManifest will be greatly reduced, and this specification was written -with such a possible future addition in mind.+
Additional levels of Manifests are required, such as per-category, and +in the eclasses, profiles and metadata directories. This ensures that a +change to a singular file causes the smallest possible overall change in +the Manifests as propagated. Creation of the additional levels of +Manifests uses the same process as described above, simply starting at a +different root point.
MetaManifest generation will take place as part of the existing process by infrastructure that takes the contents of CVS and prepares it for distribution via rsync, which includes generating metadata. In-tree -Manifest files are not checked at this point, as they are assumed to be -correct.+Manifest files are not validated at this point, as they are assumed to +be correct. +
There are two times that this may happen: firstly, immediately after the rsync has completed - this has the advantage that the kernel file cache is hot, and checking the entire tree can be accomplished quickly. @@ -194,7 +213,7 @@ package.
In the following, I've used term 'M2-verify' to note following the hash verification procedures as defined by the Manifest2 format - which compromise checking the file length, and that the hashes match. Which @@ -231,8 +250,8 @@ -
For this portion of the tree-signing work, no actions are required of the individual Gentoo developers. They will continue to develop and commit as they do presently, and the MetaManifest is added by Infrastructure during the tree generation process, and distributed to users.+
Any scripts generating Manifests and the MetaManifest may find it useful +to generate multiple levels of Manifests in parallel, and this is +explicitly permitted, provided that every file in the tree is covered by +at least one Manifest or the MetaManifest file. The uppermost +Manifest (MetaManifest) is the only item that does not occur in any +other Manifest file, but is instead GPG-signed to enable it's +validation.
While [#GLEP60] describes the addition of new filetypes, these are NOT needed for implementation of the MetaManifest proposal. Without the new filetypes, all entries in the MetaManifest would be of type 'MISC'.
As discussed by [C08a,C08b], malicious third-party mirrors may use the principles of exclusion and replay to deny an update to clients, while at the same time recording the identity of clients to attack.@@ -284,19 +310,19 @@ user-configuration setting, with the ability to override.
With only two levels of Manifests (per-package and top-level), every rsync will cause a lot of traffic transferring the modified top-level MetaManifest. To reduce this, first-level directory Manifests are -strongly recommended. Alternatively, if the distribution method -efficiently handles small patch-like changes in an existing file, -using an uncompressed MetaManifest may be acceptable (this would -primarily be distributed version control systems). Other suggestions -in reducing this traffic are welcomed.+required. Alternatively, if the distribution method efficiently handles +small patch-like changes in an existing file, using an uncompressed +MetaManifest may be acceptable (this would primarily be distributed +version control systems). Other suggestions in reducing this traffic are +welcomed.
I'd like to thank the following people for input on this GLEP.