This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: [RFC] gpg signed packages [Was: unofficial packages]
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.
I meant "implicitly" for cygwin people, not implicit for the final user =)
I'm trying to avoid devaluing the web of trust, while still keeping what
we initially implement simple.
A key's signature is only as trustable as it is the signing key.
If the key name were "Partially trusted Cygwni developers" I think no
people would "trust" that key... well out there there is also people
that signs other people key without any knowledge (not even "I've talked
by e-mail with him often") so maybe this is a bit academic.
One thing doesn't "sounds right" to me in signing the keyring itself:
once "installed" from the package it is a normal, unprotected, file.
While forging a signature is "not possible" modifying the keyring file
from remote may be feasible, even if you could reply "if people has
method to modify data on HDD they can do anything"... but any protection
is one protection more, IMHO.
Anyway not that I don't agree with your method: it's perfectly OK from
me, only I would prefered the other.
But it's not a big problem ;)
a) and b) being the same
a) and b) are different
I meant "being the same as your example" (respectively), it was a
misunderstanding.
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.
I don't think I got it.
Ahhh! maybe.
You meant (not saying your written english is bad, it's by read english
that's not perfect =P) that would be better having the "trusted key ID"
id the setup.ini so every unofficial mirror can have its own "center of
trust"?
Well, yes, could be good.
Of course people must be warned that setup.ini itself is not trusted...
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.
OK, so setup would check the "keyring" each time instead of at install
of the package time.
That removes some of my fears ;)
There's LOTS of coding to do to
get setup ready for this, and reducing that is important.
OK, after all that's the point: up and running, any improvement can be
done *later*... you're right, sometime I miss the point that "now and
good" is better that "never but perfect".
Nope. No way. No how. I've said this what, 3 times now?
Setup is DATA DRIVEN. No keys belong in setup.exe.
Your right, you're right.
I was thinking in a too "official cygwin"-centric mode.
Of course each mirror should have the method to have its own center of
trust.
Nonetheless I would give people some way to know that the setup.exe that
they download from cygwin.com is "really the setup.exe compiled by
Robert Collins itself"... remember when they hacked openssh sources
directly on ftp.openssh.org?
This would be fairly easy too: it would only need a detached signature
by you on the website, downloaded only by whom is inteersted in it.
This is in no way connected with the rest of the "trust package thing"
of this message, of course.
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!
Of course not: I only wanted to be sure that also setup.exe had a
signature (or reverse-encrypted hash, call it as you want), just that.
I don't think my english is so bad but sometimes not being my natural
language leads to strange misunderstandings ;)
--
Lapo 'Raist' Luchini
lapo@lapo.it (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)