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] |
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] |