This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]