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

[Ted Zlatanov <tzz@lifelogs.com>]

(CC to emacs-devel as I think this discussion is relevant there)

On Sat, 18 May 2013 14:05:47 +0100 João Távora <joaotavora@gmail.com> wrote: 

JT> The point [is] that needing external libraries which are not always
JT> bundled doesn't make it very "builtin".

I'm not bringing GnuTLS into the Emacs source tree, which is the only
other way to make it built-in functionality.  I understand there are
issues with external dependencies and in fact I asked that we bundle the
GnuTLS W32 DLLs with the W32 Emacs builds.  That led to a long
discussions about how that makes security our responsibility and how we
then need to deal with GnuTLS updates, and I didn't have a strong desire
to become a W32 distribution expert since I barely know that platform.
No one else picked it up, and there we are with "install it yourself" as
the recommended way to get GnuTLS to work on W32.

>> I've seen dozens of bugs related to "almost working" external TLS
>> binaries on all platforms.

JT> Yes, but have you looked closely at this particular one? The point is rather
JT> to increase robustness. That is, `open-tls-stream` could/should promise
JT> to cleanup the process buffer of its handshake garbage, so that future
JT> functions that use that resource don't see it and don't get confused by it.

JT> I'm assuming they don't need to see it, I might be wrong.

I'm not able to fix this bug or work on bugs in the external SSL/TLS support.

JT> But if I'm right and that fix is performed then you've effectively extended
JT> "imap just works" the set of W32 emacs users who type "M-x gnus" on a
JT> vanilla emacs in a system with some cygwin installation in PATH. Maybe it's
JT> a small set but I'm in it (when I'm at work).

Wouldn't you rather get GnuTLS to work by default?  Otherwise we serve
the use case "I have no secure transport, so let me use a hack by
default."

>> GnuTLS integration with Emacs.  My vote is to require GnuTLS with Emacs
>> and to only support it, but there are some questions there, mainly for
>> W32 and Mac OS X: do we auto-update GnuTLS?  What happens when the
>> GnuTLS we install conflicts with another system install?  And so on...

JT> That's all fine, I guess. I vote for that too :-)

The big problem for me is that I don't have the time or platform
knowledge to write a GnuTLS auto-installer and updater for those two
problematic platforms.  The GnuTLS developers don't want to provide this
service either.  Who will be responsible to it?  What happens when a
security vulnerability hits the DLLs we distribute with Emacs?

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.

Ted