This is the mail archive of the cygwin-apps@cygwin.com 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


----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>
Sent: Thursday, July 11, 2002 9:29 AM


> So, this proposal is actually two parts:
>    1) policy: how to handle unofficial (e.g. non-ITP'ed) but setup
> compatible ports.  My proposal: don't.  They don't need to be
> distributed via the cygwin mirror system; that's what federation is all
> about.  But, to make things easier for end users, and to give some
> slight warning against possible trojans...

I.e. the status quo today. Prc-tools and kde and cygutils are all (mostly)
setup compatible sites.

>    2) implementation:
>       (a) visually distinguish packages (or versions of official
> packages) from User URLS -- and display the site URL in the chooser.
> What's the best way to do this?

Erk. I can just see looking at a rainbow when choosing what to install.

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.

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

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

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

> I realize that (2)(a) is sort of a taboo "wouldn't it be nice if
> setup.exe..." comment; and I'm willing to give it a go with the sources,
> if no one else can.  However, it's more important to know if the
> community thinks this is a good idea or not, before wasting the time
> implementing it...

If you've got hacking time, I can suggest a few areas that would benefit
from help :}.

Rob


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