Re: GnuTLS for W32

[Ted Zlatanov]

On Tue, 03 Jan 2012 09:02:17 -0500 Eli Zaretskii <address@hidden> wrote: 

>> From: Ted Zlatanov <address@hidden>
>> Date: Tue, 03 Jan 2012 08:06:51 -0500
>> 
>> On Tue, 03 Jan 2012 02:14:19 -0500 Eli Zaretskii <address@hidden> wrote: 
>> 
>> OK, so let's do a restart after a DLL package install or upgrade.  It's
>> better than nothing.  Can this process be reused for other DLLs like the
>> libxpm DLL?  Can we activate the new DLL after Emacs restarts, so the
>> old one will remain active as long as Emacs is using it and the user is
>> not forced to restart immediately?

EZ> We can, although it'd probably still need some code changes.  E.g.,
EZ> displaying the splash image at startup will automatically load an
EZ> image library, and we will have to defer that until after the DLL is
EZ> replaced.  (Assuming I understand you correctly that you propose to
EZ> run package.el in the new, restarted instance of Emacs and replace the
EZ> DLL before it is first used.)

The mechanism is not too important from a UI perspective, as long as it
DTRT, and I don't know the W32 platform well enough to specify how it
should operate.  If you think replacing the DLL is possible entirely
from within Emacs, I'm OK with that.

As a first cut, could we have a gnutls-w32 package, version 3.09
currently, which when activated will download and install the 3.09
GnuTLS DLL if it's missing?  Where should this DLL be written?

Does W32 have APIs or mechanisms to update DLLs safely?

As an alternate solution, could GnuTLS itself have an installer and an
updater?

>> I'm not sure if multiple Emacs processes are an important use case.  I
>> would guess it's an edge case on W32

EZ> Happens to me all the time when I'm working on some bug and have the
EZ> "regular" Emacs running alongside.  Also, I understand that some
EZ> people who use Gnus have it run in a separate session.

Emacs developers are always an edge case :)

>> I'm not sure what you and Juanma want to say.  That because we don't
>> have salaried positions for tracking GnuTLS updates to Emacs, it's a
>> burden?  Or that we shouldn't even do it?  Or that we need more people
>> to run the Emacs infrastructure?  What's the problem and how can we
>> solve it?

EZ> What I want to say is this:

EZ> Bottom line, I feel that letting users download and unzip DLLs is by
EZ> far more practical for this purpose than what you suggest.  It also
EZ> has the advantage of already working.

Unlike other libraries we support with Emacs, we have a responsibility
to the user to keep GnuTLS updated.  The worst case is that their
security is compromised, not that Emacs won't run.

On W32 this is a worse problem than anywhere else IIUC (Mac OS X has
MacPorts and GNU/Linux has a billion package managers).  So, we either
tell the user to download and unzip the GnuTLS DLLs every time there's a
critical fix, or we do it automatically for them from the package.el UI,
or we pass the responsibility to the GnuTLS developers to write an
updater.  I don't think we have the option, as responsible developers,
of just ignoring that responsibility.

On Tue, 3 Jan 2012 14:37:00 +0100 Juanma Barranquero <address@hidden> wrote: 

JB> What I want to say is that is a problem already fixed elsewhere, and I
JB> see no point in diverting resources to fix it again poorly.

The problem of pushing out a critical GnuTLS fix to Emacs users on W32
is not fixed AFAIK.  We just have a DLL in a zip file.

Ted