[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on
bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on w32
Fri, 24 May 2013 15:48:20 -0400
Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux)
On Mon, 20 May 2013 19:28:40 +0300 Eli Zaretskii <address@hidden> wrote:
>> From: Ted Zlatanov <address@hidden>
>> Cc: address@hidden, address@hidden
>> Date: Mon, 20 May 2013 09:56:27 -0400
>> On Sun, 19 May 2013 18:32:37 +0300 Eli Zaretskii <address@hidden> 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
bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on w32, Eli Zaretskii, 2013/05/19