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] |
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.
Or by any key that is directly (or indirectly) signed by that key...
Signing the keyring itself is good for a human, but it's difficult to "automate" the trust thing... if the keys IN the package had been signed by the "central key" (called maybe "Cygwin matainers signing key") then GPG could automatically check that these are "valid" keys.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 :}.
Knowing each person would be best of course, but I agree completely with you that "that's the person that created the last 10 packages, and all were good" may well be enough, at least for "some time" (with some "as short as possible" but maybe countedr in YEARS ^_^).But how much trust is "enough"?
Yes, this is the big one.
Yes.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.
1) Every maintainer generates for themselves a gpg key.Tat's OK but I would (slightly) change that to:
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.
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).
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |