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

Previous Next

Full log

Message #32 received at 14380 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Ted Zlatanov <tzz <at> lifelogs.com>
Cc: 14380 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, emacs-devel <at> gnu.org
Subject: Re: bug#14380: 24.3; `network-stream-open-tls' fails in some imap
	servers on w32
Date: Sun, 19 May 2013 12:45:12 +0100

On Sun, May 19, 2013 at 4:17 AM, Ted Zlatanov <tzz <at> lifelogs.com> wrote:
> GnuTLS W32 DLLs with the W32 Emacs builds.  That led to a long
> discussions about how that makes security our responsibility and how we

I see. Indeed, bundling security stuff with your app is increasing
its responsibility manifold.

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

I don't understand. What is the hack here? External binary for TLS?
But yes, GnuTLS by default is certainly better...

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

... but then you have all these headaches.

The fix I proposed aims for the status quo, that is: make external
TLS binary support slightly more robust. My test case is even smaller:

* W32
* cygwin carrying the responsibility burden
* vanilla emacs working with tls/imap/gnus.

Thanks for the time spent in analysing this,
-- 
João Távora

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.