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
