[OpenAFS] OpenAFS RPMs and GPG signatures

David Thompson thomas@cs.wisc.edu
Thu, 12 Jun 2008 09:51:10 -0500

Simon Wilkinson wrote:
> Who do you trust?
> It would be trivial to arrange that the RPMs are automatically signed by 
> a GPG key that lives on the build machine, with an unprotected private key.

I think that regardless of whether or not you protect the signing key, 
you're trusting that the build host hasn't been compromised.  If it has, 
an adversary could do anything to your rpm _before_ it gets signed by a 
protected key (or 100 other ways someone who has compromised the host 
can defeat the signing process).

> It's harder to arrange that they're signed by a key which requires 
> manual intervention - but it would be possible for them to be signed, 
> for example, by my GPG key.

I think the question here is, who is taking responsibility for the RPMs? 
  If these are Simon Wilkinson RPMs, then I think it's fine for them to 
be signed by Simon.  If openafs.org is asserting that the RPMs are 
somehow blessed by the organization (which I think is implied by the 
current structure, but may not be intended), they should carry an 
openafs.org signature.  Choosing who signs the RPMs could make these 
relationships clearer.

> As for an OpenAFS key, who do you let sign packages with that key. What 
> happens if someone with access to that key then leaves the project, etc, 
> etc?

openafs is hardly alone in this regard.  Lots of organizations/projects 
deal with this issue.  There are a number of ways through this.

> And, ultimately, if the packages are getting signed without any form of 
> checks, do either of the latter two actually offer any more security 
> than the first?

The checks consist largely in the established relationships between the 
builders and the organization.  Somewhere you have to trust someone. 
The holder(s) of the signing key(s) ultimately are trusted.  Deciding 
who should sign the RPMs and who should have access to the signing keys 
makes that trust explicit.  Unless you (whoever openafs.org is) is going 
to audit diffs of source RPMs and rebuild/sign them, you're trusting the 
RPM builders.  The act of giving someone an openafs.org signing key 
codifies the trust.  Signing an RPM with a personal RPM key likewise 
codifies that an individual is operating on their own behalf.

Dave Thompson