This is the mail archive of the
mailing list for the Cygwin project.
Re: unofficial packages
Charles Wilson wrote:
Robert Collins wrote:
I don't like this particular approach. It isn't flexible (I can't
trust cygutils as much as I trust Redhat). It doesn't address some key
issues (for example only one file size and md5 and filepath is stored
each package-version-release-(bin|src) file.
All good points. That's why this is an RFC.
If we want package integrity I think the appropriate approach is:
- every official package is gpg signed (within the package format).
- setup validates the signature against an 'official' keychain. If the
maintainer doesn't match (i.e. Chuck signs a libxml2 upload) then setup
warns, and identifies who signed. If the signature doesn't validate,
warns about that - and much more loudly.
Yes, this requires documenting who maintains packges, but it doesn't
be easily available to end users (i.e. the user interface doesn't
Hmmm...so *setup* would have to know who maintains what, as far as
official packages go. Now, this can't be compiled-into the
executable; it has to be distributed from the mirrors. Are you
thinking encryption? 'cause that's pointless -- the decryption key
has to be bound into setup.exe; thus, available from setup's sources.
I think we could have the keyring (a document) on the mirror sites,
itself signed by Redhat's Software Signing Key (or CGF's personal key
for that matter).
Then only the single public key needs be 'bound' to SETUP.EXE. This
way, also, a signature can be "revoked" by de-listing a signer - without
getting into the PKI nest of worms. Of course, to be useful, maybe we
need to have CGF /sign/ all our keys. Now, how do I prove to Chris that
I am me? You were looking for more to do, weren't you Chris?
However, I realize we're not REALLY worried about "malicious people
decrypting the maintainer list and discovering that -- WOW! -- chuck
maintains autoconf(wrapper)" -- the information is already available
with a few web clicks (search cygwin-announce archives). Its just
that some maintainers don't want a master list with their name on it,
available to all the world in one easy-to-grab file. So, we need the
list in a file -- but let's make the barrier-to-read higher than the
existing three-clicks-to-cygwin-announce-archives method.
The benefits this has are:
1) No uglification of the user interface
2) Scalable - if I choose to trust anything from cygutils, they can
a additional keychain to validate against.
I really need to learn more about GPG.
3) Control is in the users hands - they can trust whom they want to.
they can decide not to trust the main cygwin packages if that's what
sounds good. That pesky cgf guy has been publishing broken compilers
I don't this matters. A) there aren't that many sites, and b) they can
(b) an extension of the existing "related sites" web page, to
include a section with "Here are some setup-compatible sites that offer
cygwin packages. type these URLs in to setup.exe, and press Add URL."
advertise this capability to their visitors directly, and via the cygwin
homepage when they want to announce ports etc. As a data point we
suse,debian,redhat etc announcing all the <installer>-compatible
sites that exist.
If you've got hacking time, I can suggest a few areas that would benefit
from help :}.
Well, this RFC is a long term thing -- not a "do it by next week or
else". Long term -- say in about two months -- I'll have tons of
hacking time, and that was a genuine offer of help. Short term -- not
a chance. :-( But there's no rush on this RFC -- I just wanted to get
the concept "out there", since it came up (again) in a private exchange.
I like your idea -- it addresses all of my concerns. It'll take some
work, tho, to extend the UI or setup.cfg file to add trust levels and
keyrings and suchlike...
David A. Cobb, Software Engineer, Public Access Advocate
"By God's Grace I am a Christian man, by my actions a great sinner." -- The Way of a Pilgrim; R. M. French, tr.
Life is too short to tolerate crappy software.