From: Ted Zlatanov <tzz@lifelogs.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 14380@debbugs.gnu.org, joaotavora@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 [thread overview]
Message-ID: <87y5b417nf.fsf@lifelogs.com> (raw)
In-Reply-To: <834ndxwr7r.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 20 May 2013 19:28:40 +0300")
On Mon, 20 May 2013 19:28:40 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> 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.
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
next prev parent reply other threads:[~2013-05-24 19:48 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87k3mw79iv.fsf@lifelogs.com>
2013-05-18 13:05 ` bug#14380: [gmane.emacs.bugs] bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on w32 João Távora
2013-05-19 3:17 ` Ted Zlatanov
[not found] ` <87zjvr64lt.fsf_-_@lifelogs.com>
2013-05-19 11:45 ` João Távora
2013-05-19 15:32 ` Eli Zaretskii
2013-05-20 13:56 ` Ted Zlatanov
2013-05-20 16:28 ` Eli Zaretskii
2013-05-24 19:48 ` Ted Zlatanov [this message]
2013-05-24 20:27 ` Eli Zaretskii
2013-05-10 12:49 ` João Távora
2013-05-10 14:00 ` Eli Zaretskii
2013-05-10 16:00 ` João Távora
2013-05-10 17:17 ` Eli Zaretskii
2013-05-10 20:44 ` João Távora
2013-05-11 7:06 ` Eli Zaretskii
2013-05-17 13:12 ` Ted Zlatanov
2013-05-24 22:20 ` Ted Zlatanov
2013-05-25 6:49 ` Eli Zaretskii
[not found] ` <CALDnm50KHS7wOKUpQJQHb4V_PLfQs6VkjEsRmPgY=R5x0eEuUg@mail.gmail.com>
2013-05-19 15:44 ` Eli Zaretskii
2013-05-19 17:57 ` João Távora
2013-05-19 19:01 ` Eli Zaretskii
2013-05-19 23:05 ` Ted Zlatanov
[not found] ` <87txly4ll9.fsf@lifelogs.com>
2013-05-20 2:08 ` Juanma Barranquero
2013-05-20 22:07 ` João Távora
[not found] ` <CALDnm51-4aTee3NGoRp+=T6MuTV3xD9P4Ed1yZLU_E5k_r5hGw@mail.gmail.com>
2013-06-05 15:06 ` Ted Zlatanov
[not found] ` <87obbk1trn.fsf@lifelogs.com>
2013-06-05 16:42 ` Glenn Morris
2013-06-05 18:10 ` Ted Zlatanov
2013-06-08 0:58 ` Glenn Morris
2013-06-06 8:15 ` João Távora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y5b417nf.fsf@lifelogs.com \
--to=tzz@lifelogs.com \
--cc=14380@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=joaotavora@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).