Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] Summary of GPG Discussions / For Real Proposal

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: "Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] Summary of GPG Discussions / For Real Proposal
  • Date: Wed, 17 Aug 2005 13:35:27 -0500

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




Archive powered by MHonArc 2.6.24.

Top of Page