Re: GnuTLS for W32

[Ted Zlatanov]

On Thu, 05 Jan 2012 00:36:57 -0500 Eli Zaretskii <address@hidden> wrote: 

>> From: Ted Zlatanov <address@hidden>
>> 
>> I think, to get this working, we need a list of critical ELPA packages
>> that Emacs will check for updates on startup and alert the user to
>> upgrade.  By default that list should be empty on all platforms, except
>> on W32 it will contain the "gnutls-w32" package.

EZ> Again, why are we treating MS-Windows specially?  Why shouldn't Emacs
EZ> issue the same alert on GNU and Unix systems, if GnuTLS is found to be
EZ> unavailable?  The fact that several distributions have Emacs depend on
EZ> GnuTLS does not mean all of them do or will, and let's not forget that
EZ> even in the year 2012 users can build their own Emacs (without
EZ> GnuTLS).

You're right.  Do you agree with the general idea of checking for
critical updates on startup, though?

I would actually also like to bundle trusted certificates.  The
Diginotar compromise showed the need for managing the certs proactively,
and we can't rely on what's on W32 systems.  On other platforms we can
let the distribution choose the right cert bundle.  Right now, gnutls.el
will take a list of trustfiles or default to
/etc/ssl/certs/ca-certificates.crt, which is hardly ideal for all
platforms.

On Thu, 5 Jan 2012 03:36:38 +0100 Juanma Barranquero <address@hidden> wrote: 

JB> The moment the packages are accesible from the official site, there's
JB> certain responsibilities. For example, to issue security upgrades as
JB> fast as possible.
...
JB> Responsibility and obligation are disjoint concepts. I don't mind the
JB> load, but I hate accepting (not personally, but as a project) the
JB> responsibility to do things, like compiling GnuTLS binaries and
JB> distributing them, that are utterly disconnected from Emacs
JB> development per se. The moment we do that, people will expect we also
JB> provide up-to-date binaries for image libs, libxml2, d-bus, you name
JB> it.

I think the risk of providing out-of-date libxml2 or libxpm is much
smaller than providing out-of-date GnuTLS.  So while I understand your
concern about this slippery slope, I think we can resist it, and regular
releases can address the general need for updates.

On Thu, 05 Jan 2012 00:24:56 -0500 Eli Zaretskii <address@hidden> wrote: 

>> From: Ted Zlatanov <address@hidden>

>> I'm concerned about GnuTLS updates after the install.  An ELPA package
>> could do that, a simple DLL drop couldn't.

EZ> That's true, but if we assume that an urgent need to upgrade GnuTLS
EZ> will not be too frequent, we can update it with each release and in
EZ> binaries of development snapshots.  That would probably do 80% of the
EZ> job, if not more.

Unfortunately security issues and their fixes are inherently urgent and
unpredictable (e.g. the Diginotar compromise).  Note above about my
desire to also provide cert bundles in this package, so it could do much
more than a DLL drop.  But if we go with Joakim's full installer idea,
that would do the job better than package.el could.

On Thu, 05 Jan 2012 06:40:27 +0100 address@hidden wrote: 

j> If I were to do this I would make a build bot that produced daily
j> binaries of the installer of a complete Emacs installation including the
j> dll files. I would not bother with partial updating of particular dll:s
j> at this time.

If we tell the user to reinstall because GnuTLS is out of date, would
that be a big burden?  I guess that's a fourth option for distributing
and updating GnuTLS, which could be combined with the ELPA package for
notifications:

1) zipfile drop

2) ELPA package in the GNU ELPA archive with startup GnuTLS version check

3) GnuTLS standalone installer+updater

4) Emacs installer+updater

Combining (4) and (2) seems most convenient for the users: they will
have a single installer for all of Emacs (a convenience that goes beyond
this thread), and they'll get notified on all platforms when GnuTLS is
out of date.

Ted