--- xml/htdocs/proj/en/glep/glep-0058.html 2010/01/13 01:02:36 1.2 +++ xml/htdocs/proj/en/glep/glep-0058.html 2010/01/13 03:28:33 1.3 @@ -27,9 +27,9 @@ Title:Security of distribution of Gentoo software - Infrastructure to User distribution - MetaManifest -Version:1.5 +Version:1.6 -Last-Modified:2010/01/13 00:57:49 +Last-Modified:2010/01/13 03:26:53 Author:Robin Hugh Johnson <robbat2 at gentoo.org>, @@ -45,7 +45,7 @@ Updated:November 2007, June 2008, July 2008, October 2008, January 2010 -Post-History:Decemeber 2009 +Post-History:December 2009 @@ -145,7 +145,7 @@ evolution of Manifest2 entry types per [#GLEP60]), and place them into the COVERED set.
  • Recursively add every file in the directory to the ALL set, -pursusant to the exclusion list as mentioned in [#GLEP60].
  • +pursuant to the exclusion list as mentioned in [#GLEP60].
  • Produce a new set, UNCOVERED, as the set-difference (ALL)-(COVERED). @@ -159,7 +159,7 @@ file, so that a MetaManifest may be tied back to a tree as distributed by the rsync mirror system. The string of 'metadata/timestamp.x' should be included to identify this revision -of MetaManifest generation. Eg: +of MetaManifest generation. e.g.: "Timestamp: metadata/timestamp.x: 1215722461 Thu Jul 10 20:41:01 2008 UTC" The package manager MUST not use the identifying string as a filename.
  • The MetaManifest must ultimately be GnuPG-signed.
      @@ -176,7 +176,7 @@ 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 eclases), the size of the +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.

      MetaManifest generation will take place as part of the existing process @@ -204,7 +204,7 @@ automated Gentoo keys. See [#GLEPxx+3] for full details regarding verification of GnuPG signatures. 1. Abort if the signature check fails. -

    1. Check the Timestamp header. If it is significently out of date +
    2. Check the Timestamp header. If it is significantly out of date compared to the local clock or a trusted source, halt or require manual intervention from the user.
    3. For a verification of the tree following an rsync:
        @@ -224,7 +224,7 @@
      1. If checking at the installation of a package:
        1. M2-verify the entry in MetaManifest for the Manifest
        2. M2-verify all relevant metadata/ contents if metadata/ is being -used in any way (optionally done before dependancy checking).
        3. +used in any way (optionally done before dependency checking).
        4. M2-verifying the contents of the Manifest.
        5. Perform M2-verification of all eclasses and profiles used (both directly and indirectly) by the ebuild.
        6. @@ -272,12 +272,12 @@

          On all rsync mirrors directly maintained by the Gentoo infrastructure, and not on community mirrors, there should be a new module 'gentoo-portage-metamanifests'. Within this module, all MetaManifests -for a recent time frame (eg one week) should be kept, named as +for a recent time frame (e.g. one week) should be kept, named as "MetaManifest.$TS", where $TS is the timestamp from inside the file. The most recent MetaManifest should always be symlinked as MetaManifest.current. The possibility of serving the recent -MetaManifests via HTTPS should also be explored to mitigate MitM -attacks.

          +MetaManifests via HTTPS should also be explored to mitigate +man-in-the-middle attacks.

          The package manager should obtain MetaManifest.current and use it to decide is the tree is too out of date per operation #2 of the verification process. The decision about freshness should be a @@ -286,10 +286,10 @@

          MetaManifest size considerations

          With only two levels of Manifests (per-package and top-level), every -rsync will cause a lot of traffic transfering the modified top-level +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 -efficently handles small patch-like changes in an existing file, +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.

          @@ -330,7 +330,7 @@