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

Previous Next

Full log

View this message in rfc822 format

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14380 <at> debbugs.gnu.org, joaotavora <at> gmail.com
Subject: bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on w32
Date: Fri, 24 May 2013 15:48:20 -0400

On Mon, 20 May 2013 19:28:40 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote: 

>> From: Ted Zlatanov <tzz <at> lifelogs.com>
>> Cc: 14380 <at> debbugs.gnu.org,  joaotavora <at> gmail.com
>> Date: Mon, 20 May 2013 09:56:27 -0400
>> 
>> On Sun, 19 May 2013 18:32:37 +0300 Eli Zaretskii <eliz <at> 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.

EZ> What risk? what responsibility?

The risk is that their version of GnuTLS is out of date.  The
responsibility is to update it regularly.

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

Installing and keeping GnuTLS up to date should not be the
responsibility of the user.

To put it another way, if you want that responsibility, you're in a very
small percentage of the Emacs user population.  Most users don't want it
and will neglect it badly.

EZ> And mind you, in view of the latest sparring between GnuTLS developers
EZ> and the FSF (which I have no idea how ended, except that the license
EZ> was downgraded a bit and the official site moved), I'm not even sure
EZ> the FSF will agree to distribute GnuTLS with Emacs, on any platform.
EZ> Why should Emacs development enter this minefield?

That's a reasonable question.  I think we have to face it regardless of
the outcome of this discussion because Emacs depends on GnuTLS for SSL
and TLS communications right now.

As far as I know GnuTLS status is back to "kosher."

EZ> And for what? for solving a non-existing problem of installing a
EZ> simple package?

Installing is easy.  Keeping it up to date isn't.  Security updates are
tedious and tedious things get overlooked.

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

I see it as a responsibility we're avoiding.  But if we had these
regular builds, how would the user know about a critical update he
really must install?

See here http://bugs.python.org/issue17425 for an example of how the
Python community dealt with an security issue in the OpenSSL libraries
they ship for Windows.  I guess we have to answer the question of
whether that's a standard we as Emacs developers should aspire to, or
not.

Ted

Previous Next

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