Public SourceMage Discussion List

["Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>]

We had a pretty productive discussion about all these GPG threads on IRC
today; I'm going to try and summarize what the consensus of that
discussion and these ML threads seems to be.  Please jump in if I get
something wrong.


1) A primary reason GPG integrity checking was included in sorcery was
   to offload all the awareness of various hash algorithms/etc. to GPG.
   For this reason it is a goal to eventually move *all* integrity
   checks to GPG instead of using the old MD5[] or even the newer
   SOURCE_HASH.

2) This raises questions about what it means for a developer to sign an
   upstream tarball when no upstream key/signature is available.  To
   keep things clear to our users (and developers):

   a) Developers should not use their personal key for signing tarballs.
      They should create a new key used only for this.  "What it means"
      for a developer to sign a tarball is different from what it means
      for them to sign someone else's key in a web of trust context;
      more on this is below.

   b) Developers already have secure access to p4, so they don't
      necessarily need to get their GPG keys verified by other
      developers.  They should upload them over stunnel to the grimoire
      directly.

3) Upstream keys are always preferred, since they maintain a complete
   validation chain of the source and require the least ongoing
   maintenance for gurus.  However, before including an upstream key in
   the grimoire(s), gurus should attempt to verify the key at least
   three of the following ways:

   a) Get the key/fingerprint from the primary distribution site for the
      package in question.

   b) Get the key from one of the public keyservers (either pgp.mit.edu
      or subkeys.pgp.net).

   c) Get the key/fingerprint from an official post to a mailing list
      for the package in question.

   d) Have a version of the key that is signed by a key we already
      include and have three-method verification for.

   "Validation" means that the fingerprint retrieved in the above method
   matches the fingerprint of the key to be included in the grimoire.
   For example, getting the key from the primary upstream site and
   comparing the fingerprint against the same key from a keyserver and a
   fingerprint published to the relevant project's mailing list counts
   as three methods.
  
4) For both GPG sigs and hashes, sorcery will be modified to allow gurus
   to indicate the amount of validation the guru was able to do on the
   sources.  This indication will be made in the form of a numeric level
   added to the existing SOURCE_{GPG,HASH} variable as follows:
  
   a) SOURCE_HASH=<hashname>:<hashcode>:<level>

   b) SOURCE_GPG=<key>:<sig>:<level>
  
   Users will then be able to indicate the minimum level they are
   willing to accept.  Anything below this level will be counted as a
   verification failure, at which point the existing user preference for
   how to deal with verification failures will apply (ignore, continue,
   etc.).
  
   The exact level specification has not been determined yet, but the
   following has been suggested and seems to have consensus:
  
   a) Level 0: Verification is explicitly not included.  
  
   b) Level 1: The guru downloaded the sources from the primary upstream
      distribution site and verified they compiled and ran.
    
   c) Level 2: The guru verified the downloaded sources matched a hash
      published by the upstream authors.

   d) Level 3: The spell is using an upstream key which has been
      verified using at least one of the above listed methods.

   e) Level 4: The spell is using an upstream key that has been verified
      using three of the above listed methods.
  
   Level 0 applies to things like CVS versions of spells.  Levels 1 and
   2 apply to spells using SOURCE_HASH or that are guru-signed.  Level 3
   and 4 apply to vendor-signed sources.  If no level is specified in
   SOURCE_{HASH,GPG}, level 1 will be assumed.

5) Gurus who are unable or unsure how to do upstream key or source
   verification can make updates to the best of their ability in devel
   and mark it WIP, and someone with GPG/verification experience will
   perform the key or source verification from there.  [Should we assign
   a bugzilla contact for this?]  If an update needs to go from devel to
   test before the verification has been done, this can happen, with the
   understanding the stated verification level may need to be
   temporarily degraded as a result.

6) When an upstream key is included in the grimoire, the relevant
   HISTORY file should be updated to indicate the way(s) in which it was
   verified.  If less than three verifications were achieved but more
   were attempted this should be noted as well.  For non-vendor-signed
   spells, when upstream sources are updated and the version update
   happens, the relevant HISTORY file entry should include the way the
   sources were verified if the stated verification level is higher than
   1.

7) The following are valid bugs at the point these standards are agreed
   on and a version is posted as documentation to the website:

   a) Spells which use MD5[] instead of either SOURCE_HASH or
      SOURCE_GPG.  [Is this going to be a new 1.0 target?  It's easy to
      change to at least SOURCE_HASH via a script.]

   b) Spells which use hashes or guru signatures when upstream
      keys/signatures are available.

   c) Spells which include upstream keys but have not attempted the
      three-method verification described above, or have not documented
      the verifications performed in the relevant HISTORY log.

   The following are *not* valid bugs:

   a) Spells which include upstream keys without the three-method
      verification described above IFF that verification has been
      attempted and was not possible, and the attempts and results are
      documented in the relevant HISTORY log.

   b) Spells which do not include an upstream key ("level" is < 3) when
      no upstream key is available (duh).

   The following are not valid bugs yet, but may be in the future:

   a) Spells which use SOURCE_HASH instead of SOURCE_GPG.


Comments?

Attachment: pgpaRqPH2h6SM.pgp
Description: PGP signature