On 12 Jun 2008, at 15:51, David Thompson 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).
Indeed. That was my point. None of the other mechanisms for signing
(attended keys, organisational keys ...) actually give you any more
assurance about RPM integrity than a random key that resides on the
disk of the build machine and says "Machine X built this RPM".
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.
I don't think that the GPG key conveys anything with regards to these
relationships. In fact, it may well just serve to muddy the water.
What happens if we make the decision that the builder signs the RPM
(after all, the builder is the only one who can actually vouch for
the RPMs contents - be that a person, or an automated process) The
signature has no bearing on the "official", or not, nature of the
package. Ultimately, the place you get the RPMs from is probably the
key signifier of their status - especially for users for whom GPG
keys and webs of trust are a black art.
If it would be useful to people, I'm quite happy to start signing the
Fedora RPMS with a "OpenAFS build system (lochranza) key". Hey, I'll
even sign that key. I strongly suspect that anything more than doing
this is just snake oil.
Simon.
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
