From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on w32 Date: Fri, 24 May 2013 23:27:07 +0300 Message-ID: <8338tcrun8.fsf@gnu.org> References: <87k3mw79iv.fsf@lifelogs.com> <87zjvr64lt.fsf_-_@lifelogs.com> <83r4h3vvca.fsf@gnu.org> <878v394uwk.fsf@lifelogs.com> <834ndxwr7r.fsf@gnu.org> <87y5b417nf.fsf@lifelogs.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1369427300 10115 80.91.229.3 (24 May 2013 20:28:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 May 2013 20:28:20 +0000 (UTC) Cc: 14380@debbugs.gnu.org, joaotavora@gmail.com To: Ted Zlatanov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 24 22:28:20 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ufyb4-0001jI-5s for geb-bug-gnu-emacs@m.gmane.org; Fri, 24 May 2013 22:28:18 +0200 Original-Received: from localhost ([::1]:49166 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ufyb3-0006MZ-QF for geb-bug-gnu-emacs@m.gmane.org; Fri, 24 May 2013 16:28:17 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ufyau-0006LA-50 for bug-gnu-emacs@gnu.org; Fri, 24 May 2013 16:28:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ufyar-00066M-D7 for bug-gnu-emacs@gnu.org; Fri, 24 May 2013 16:28:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44305) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ufyar-00066F-8V for bug-gnu-emacs@gnu.org; Fri, 24 May 2013 16:28:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Ufybl-00060h-IL; Fri, 24 May 2013 16:29:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org, bugs@gnus.org Resent-Date: Fri, 24 May 2013 20:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14380 X-GNU-PR-Package: emacs,gnus X-GNU-PR-Keywords: Original-Received: via spool by 14380-submit@debbugs.gnu.org id=B14380.136942729523027 (code B ref 14380); Fri, 24 May 2013 20:29:01 +0000 Original-Received: (at 14380) by debbugs.gnu.org; 24 May 2013 20:28:15 +0000 Original-Received: from localhost ([127.0.0.1]:60894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ufyay-0005zH-OT for submit@debbugs.gnu.org; Fri, 24 May 2013 16:28:13 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:39548) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ufyav-0005yy-Nm for 14380@debbugs.gnu.org; Fri, 24 May 2013 16:28:11 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MNB00B00KPO1L00@a-mtaout23.012.net.il> for 14380@debbugs.gnu.org; Fri, 24 May 2013 23:27:05 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MNB00ANKKT5Y130@a-mtaout23.012.net.il>; Fri, 24 May 2013 23:27:05 +0300 (IDT) In-reply-to: <87y5b417nf.fsf@lifelogs.com> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:74536 Archived-At: > From: Ted Zlatanov > Cc: 14380@debbugs.gnu.org, joaotavora@gmail.com > Date: Fri, 24 May 2013 15:48:20 -0400 > > EZ> What risk? what responsibility? > > The risk is that their version of GnuTLS is out of date. That happens with dozens of packages on each user's machine. There's nothing in GnuTLS that makes it unique in this regard. Moreover, the latest and greatest GnuTLS sometimes simply won't build on some systems. Like with the latest release, for example. How is it a good idea to upgrade to a version that is broken? And if the latest version is not always the one to upgrade to, then who will make the research required to tell users to which version to upgrade? You? I did that research for the single version whose Windows port I made available. I built it, fixed the build problems, tested it, fixed the problems revealed by that, and after doing all that I could in good faith tell people they can use that version without too much fear. Why is it safer for users to upgrade to a newer version than to stay with the one I tested? Shouldn't whoever wants to tell them to upgrade invest a similar effort in that newer version? If she doesn't, she is actually shifting the responsibility to the users anyway! > The responsibility is to update it regularly. Or not. Blindly upgrading could get users in trouble. > 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. Says you. But since there's no one else to pick up the gauntlet, that's where this responsibility will need to rest. If J.R. Hacker needs GnuTLS today, he has no one else but himself to rely on. All we, the Emacs developers, do is just talk. > 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. Again, nothing new or special here. > As far as I know GnuTLS status is back to "kosher." Not sure based on what you say this. > 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. I'm sorry, but you are expecting from the Emacs development something it can never provide in its present shape and form. Tracking security issues to this degree in even a single package is a very time consuming job. Unless we have several volunteers on board taking responsibility for the various packages which Emacs supports, what you seem to want is nothing more than a pipe dream. I don't see any such volunteers; in fact, I don't even see a single one. If we had such an individual, my year-old port would have been replaced by newer ones already. (Of course, the Windows build in GnuTLS is regularly broken, so it's not really easy, either.) Until that changes, all this talk is just a huge waste of energy. If you think this kind of effort is possible, how about if you present a complete realistic plan for having a secure Emacs, name individuals who would test the releases of those packages for security issues, and make sure any problems that are detected are promptly fixed on all platforms we support, etc.? Otherwise, let's just stop these endless discussions and admit that we don't have the resources to live up to it.