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
UW-Madison
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
