[RFC] gpg signed packages [Was: unofficial packages]
Robert Collins
rbcollins@cygwin.com
Wed Sep 25 06:34:00 GMT 2002
On Wed, 2002-09-25 at 23:18, Lapo Luchini wrote:
> 2) cygwin has a "implicitly trusted" key, whose private key is used by
> CGF, Corinna, or any "central cygwin trusted member"
I don't think we want an implicitly trusted key. We do need a central
key of sorts, but that is different because the user must choose to
trust it.
> 3) the mantainer keys are signed by the key in 2, which should have a
> name which specifies that it's a sort of meta-key that gives no *BIG*
> trust in key, but WoT after all is this way: each one assigns "how much
> trust it needs" in signatures, and everyone else decides then to trust
> him or not.
This is the same as signing the keychain, except that it requires more
effort to make reliable. I'd rather sign that key foo is for person bar
**for cygwin setup/packages *** than sign the key without the full
rigamarole of a key signing party.
I'm trying to avoid devaluing the web of trust, while still keeping what
we initially implement simple.
> 4) setup validates package signers which used a key that is both in that
> keyring and is signed by the central key (or maybe indirectly signed,
> that's an option to consider but I don't thing it is needed)
> a) and b) being the same
a) and b) are different, and should be displayed as different. This is
orthogonal to the keychain issue, it's the package-maintainer database
that is needed.
> What do you think about it?
I think that it runs into the objections I had at the beginning of the
whole thread:
It locks setup into a cygwin-master-and-mirrors only, and prevents
individual sites overriding what is most trustworthy. (2).
IMO it's more maintenance for Chris/Corinna/whoever on the keychain
management. (3)
It doesn't differentiate between (in debian-speak) NMU's, and trojans.
That is bad.
> IMHO the "signed keyring" has the same "effect" but in fact once
> installed it has no "connection" with the central key any more, that way
> instead we could also put the key on keyservers (properly signed by CGF
> or Corinna etc. etc.).
Huh? I'm not sure what you mean. I envisage setup calling gpg with a
specific keyring argument to access the 'signed' keyring, and validating
that with a checksum against stored in setup.ini. Remember: we're trying
for a simple-and-easy solution, for now. There's LOTS of coding to do to
get setup ready for this, and reducing that is important.
> >setup.exe has no encryption key bound to it.
> >
> IMHO, once created, setup.exe should contain at least the fingerprint of
> the "central key" (that would otherways only be "one of the keys in the
> keyring") and, also important, some way to check its own MD5 at running
> time (though right now I have no simple idea how a program can contain
> its own MD5 unless he knows where it is stored and assumes that zeroes
> should be there for MD5 calculation).
> This would be good for virus and simple unintended modifies.
> Or better a detached signature by the central key, also easier to
> generate or check.
Nope. No way. No how. I've said this what, 3 times now?
Why do you want setup.exe to be bound to a single key? I really don't
understand what you want to achieve with that.
Setup is DATA DRIVEN. No keys belong in setup.exe. regardless of whether
we use a 'signed keyring' or a 'keyring of signed keys', or 'both' -
setup does not need a key fingerprint. Once you have the keys available
you can check setup.ini, setup.exe, whatever you want to. But setup.exe
is not a trusted distribution method for a key!
Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20020925/22046c7c/attachment.sig>
More information about the Cygwin-apps
mailing list