unofficial packages

[Charles Wilson]

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