This is the mail archive of the 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]

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.


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). *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.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]