bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on w32

[Eli Zaretskii <eliz@gnu.org>]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Cc: 14380@debbugs.gnu.org,  joaotavora@gmail.com
> Date: Mon, 20 May 2013 09:56:27 -0400
> 
> On Sun, 19 May 2013 18:32:37 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 
> 
> >> My proposal would be to push out the next Emacs bundled with the latest
> >> GnuTLS DLLs, only support GnuTLS, provide users with instructions on
> >> updating them, and treat GnuTLS vulnerabilities as Emacs
> >> vulnerabilities.  This is not ideal but IMO better than the current
> >> situation.
> 
> EZ> I see no problems with the current situation.  Installing precompiled
> EZ> GnuTLS from a zip file is a snap.
> 
> That's only a small part of the risk and responsibility we're shifting
> onto the Emacs users.

What risk? what responsibility?

A user who installs software on her computer is already trusted with
certain responsibilities, because a single mistyped command or a badly
built package can easily shut down a perfectly healthy system for
hours, if not days.  Users install dozens of packages needed to create
a workable environment for whatever they need to accomplish.  Why is
GnuTLS so special?

And mind you, in view of the latest sparring between GnuTLS developers
and the FSF (which I have no idea how ended, except that the license
was downgraded a bit and the official site moved), I'm not even sure
the FSF will agree to distribute GnuTLS with Emacs, on any platform.
Why should Emacs development enter this minefield?  And for what? for
solving a non-existing problem of installing a simple package?  Don't
we have better places to apply our time and energy?

Don't misunderstand me: if someone decides to provide regular builds
of GnuTLS ready to be downloaded and installed, I will applaud that
person.  Heck, it will be one less duty for me, for starters, as far
as the Windows binaries are concerned.  But please don't represent
this as a must for Emacs, because it isn't.