This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: unofficial packages
Robert Collins wrote:
I don't like this particular approach. It isn't flexible (I can't choose to
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 for
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, setup
warns about that - and much more loudly.
Okay...
Yes, this requires documenting who maintains packges, but it doesn't have to
be easily available to end users (i.e. the user interface doesn't have to
expose it).
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.
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 publish
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. (i.e.
they can decide not to trust the main cygwin packages if that's what tickles
their fancy).
sounds good. That pesky cgf guy has been publishing broken compilers
lately. :-)
(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."
I don't this matters. A) there aren't that many sites, and b) they can
advertise this capability to their visitors directly, and via the cygwin
homepage when they want to announce ports etc. As a data point we don't see
suse,debian,redhat etc announcing all the <installer>-compatible specialist
sites that exist.
'Kay.
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...
--Chuck