Re: [RFC] gpg signed packages [Was: unofficial packages]

[Robert Collins <rbcollins at cygwin dot com>]

On Mon, 2002-09-23 at 21:54, Lapo Luchini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I was thinking abut it (again)... but a little search avoided me a
> "duplicate" proposal... So I will answer to latest messages I can find
> about it, as I'm very interested in the thing.
> 
> - From message 
> http://sources.redhat.com/ml/cygwin-apps/2002-07/msg00403.html
> 
>  >I think we could have the keyring (a document) on the mirror sites,
>  >itself signed by Redhat's Software Signing Key (or CGF's personal key
>  >for that matter).
> Having a keyring itself signed is not that useful: it doesn't add any
> "trust" in the gpg trust system. Here "trust" is the central thing...
> people can assume to trust the key contained in setup.exe, it would be
> hard otherways, but at least on the developer side more trust is needed
> IMHO: each mantainer's key should have "enough trust" in the eyes of RH
> (or CFG itself, doesn't change the point as far as I'm concerned).

Having a signed keyring is very useful. Not for trust per se, but rather
for ease of key distribution. 
Lets start with setup.exe: Should we embed a key in it? 
A: No. 
We should not embed a key in it, because that forces all packages to be
signed by one and only one matching key.
So, you say 'well, how do we get a list of keys that *can* sign
packages?
A: We provide a keyring in a package - and that keyring is signed. So
you *know* that if someone is on that keyring, then (lets say Chris)
trusts them as a package maintainer. Of course individual keys should be
signed where possible :}.
 
> But how much trust is "enough"?

Yes, this is the big one.

> Let's see what other approaches are using... only one that comes to my
> mind is the Debian package mantainership method: every mantainer needs a
> trusted key to upload a package.
...

> Of course Debain's main method to authenticate new mantainers is to have
> them have their key signed by a previous mantainer, as their mantainers
> are quite a big number of people and are present in almost any country.

Sure. There is a general issue with gpg and building a web of trust -
that of trusting the signers, and identifying the users. Here, IMO,
we're not really worried about WHO someone is, rather that they are the
person that has consistently offered support/advice/patches/package foo/
... I.e. physical identification is orthogonal to simple assertion that
I am myself. Much as my DSA key lets me into sources.redhat.com. Chris
has never met me, or spoken on the phone - but I am 'trusted'.

I'm not against building a web of trust of cygwin developers, but I do
think that it is a separate issue to getting signed packages in a sane
fashion.
 
I think that the requirements for package signing are really quite
simple, as I outlined earlier in the referenced thread. 

To recap:

1) Every maintainer generates for themselves a gpg key.
2) We list a set of tuples in a 'trusted' database somewhere:
maintainer-pubkey-package
3) A gpg signed version of this database is available for setup.exe to
download, and referenced from (or perhaps is in) setup.ini.
4) Setup validates that package signers are 
  a) on the list
  b) signing their own package.
  Exceptions to a) result in LOUD warnings.
  Exceptions to b) result in minor warnings.

Finito. End of story. That's it. Nice and simple.
Note some corolaries (sp?):
+'s:
setup.exe has no encryption key bound to it. 
Third party sites - internal corporate sites for instance - can add
their own maintainers without cross-signing activity with cygwin. The
setup.exe UI could (should?) inform users when third party sites offer
packages available from 'official' mirrors anyway.

-'s:
Setup.exe can't tell what is an official mirror and whats not, although
it can tell when one mirror is official, and one is not. Telling who's
an 'official' mirror requires binding a key to setup.exe which I don't
think we should do. What we can do is allow the user to set trust levels
for keys on their keyring. So, we suggest that they trust the cygwin
keyring signer fully (for setup.exe purposes), sidestepping this whole
issue.

Rob

Attachment: signature.asc
Description: This is a digitally signed message part