Re: GnuTLS for W32

[joakim]

Ted Zlatanov <address@hidden> writes:

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

I think using a patcher should be sufficient:
http://wiz0u.free.fr/prog/WPatch/
That way we get a one stop solution for all changes.

Surely there must be an existing nsis installer for Emacs somewhere? If
there isn't I can provide a skeleton for someone else to tweak. Emacs
ought to be fairly easy to make an installer for since you basically
just copy the binaries somewhere and run out of tree. (I suppose, I'm
not familiar with how people run Emacs on Windows these days)

BTW the Nsis compiler can run on Gnu/Linux using Wine. There is a native
version as well but I never got it working properly. Also you will be
surprised at how arcane the Nsis language is(partly an artefact of the
domain), so one is often tempted to use something else. Last time I
checked the alternatives were worse, but that might have changed.



> Ted
>

-- 
Joakim Verona