From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov 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 18:20:55 -0400 Organization: =?UTF-8?Q?=D0=A2=D0=B5=D0=BE=D0=B4=D0=BE=D1=80_?= =?UTF-8?Q?=D0=97=D0=BB=D0=B0=D1=82=D0=B0=D0=BD=D0=BE=D0=B2?= @ Cienfuegos Message-ID: <87li7410l4.fsf@lifelogs.com> 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> <8338tcrun8.fsf@gnu.org> Reply-To: bug-gnu-emacs@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1369434144 12406 80.91.229.3 (24 May 2013 22:22:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 May 2013 22:22:24 +0000 (UTC) To: 14380@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 25 00:22:24 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 1Ug0NU-0005Qk-7x for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 May 2013 00:22:24 +0200 Original-Received: from localhost ([::1]:34930 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ug0NT-0008Je-Pd for geb-bug-gnu-emacs@m.gmane.org; Fri, 24 May 2013 18:22:23 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39775) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ug0NK-0008JU-Od for bug-gnu-emacs@gnu.org; Fri, 24 May 2013 18:22:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ug0NB-0002KW-Ar for bug-gnu-emacs@gnu.org; Fri, 24 May 2013 18:22:14 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ug0NB-0002KN-7H for bug-gnu-emacs@gnu.org; Fri, 24 May 2013 18:22:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Ug0O5-0001fh-M7; Fri, 24 May 2013 18:23:01 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Ted Zlatanov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org, bugs@gnus.org Resent-Date: Fri, 24 May 2013 22:23: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: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.13694341556356 (code B ref -1); Fri, 24 May 2013 22:23:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 24 May 2013 22:22:35 +0000 Original-Received: from localhost ([127.0.0.1]:32837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ug0Ne-0001eQ-9t for submit@debbugs.gnu.org; Fri, 24 May 2013 18:22:34 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56531) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ug0Na-0001e0-FP for submit@debbugs.gnu.org; Fri, 24 May 2013 18:22:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ug0MU-0002Dq-KB for submit@debbugs.gnu.org; Fri, 24 May 2013 18:21:27 -0400 Original-Received: from lists.gnu.org ([208.118.235.17]:44480) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ug0MU-0002Dm-Gv for submit@debbugs.gnu.org; Fri, 24 May 2013 18:21:22 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39622) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ug0MO-0008FJ-Da for bug-gnu-emacs@gnu.org; Fri, 24 May 2013 18:21:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ug0MH-0002Bd-I6 for bug-gnu-emacs@gnu.org; Fri, 24 May 2013 18:21:16 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:36143) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ug0MH-0002BT-8Y for bug-gnu-emacs@gnu.org; Fri, 24 May 2013 18:21:09 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ug0MF-0004aS-ND for bug-gnu-emacs@gnu.org; Sat, 25 May 2013 00:21:07 +0200 Original-Received: from pool-72-93-26-80.bstnma.east.verizon.net ([72.93.26.80]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 25 May 2013 00:21:07 +0200 Original-Received: from tzz by pool-72-93-26-80.bstnma.east.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 25 May 2013 00:21:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: bug-gnu-emacs@gnu.org Original-Lines: 102 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pool-72-93-26-80.bstnma.east.verizon.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:GiwHxah+TQwvI5DjdeJhPy9nPwo= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x 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:74539 Archived-At: On Fri, 24 May 2013 23:27:07 +0300 Eli Zaretskii wrote: >> 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. EZ> That happens with dozens of packages on each user's machine. There's EZ> nothing in GnuTLS that makes it unique in this regard. Yes, of course. I don't know the other packages we require to enable extra features on W32, sorry. I think GnuTLS is somewhat unique in this regard by being the only way to do secure communications with the outside world, but it's worth considering putting the other packages under the same mechanism as GnuTLS for installations and updates. EZ> Moreover, the latest and greatest GnuTLS sometimes simply won't build EZ> on some systems. Like with the latest release, for example. How is EZ> it a good idea to upgrade to a version that is broken? And if the EZ> latest version is not always the one to upgrade to, then who will make EZ> the research required to tell users to which version to upgrade? EZ> You? Yes, possibly. EZ> I did that research for the single version whose Windows port I made EZ> available. I built it, fixed the build problems, tested it, fixed the EZ> problems revealed by that, and after doing all that I could in good EZ> faith tell people they can use that version without too much fear. EZ> Why is it safer for users to upgrade to a newer version than to stay EZ> with the one I tested? Shouldn't whoever wants to tell them to EZ> upgrade invest a similar effort in that newer version? If she EZ> doesn't, she is actually shifting the responsibility to the users EZ> anyway! You're right. It's a lot of work. I appreciate it very much. I hope to be able to find the resources to make these reviews happen. >> Installing and keeping GnuTLS up to date should not be the >> responsibility of the user. EZ> Says you. But since there's no one else to pick up the gauntlet, EZ> that's where this responsibility will need to rest. If J.R. Hacker EZ> needs GnuTLS today, he has no one else but himself to rely on. All EZ> we, the Emacs developers, do is just talk. I like to ask before I make changes, hence my request for votes in emacs-devel. Sorry if it seems like empty talk to you. >> As far as I know GnuTLS status is back to "kosher." EZ> Not sure based on what you say this. Monitoring the GnuTLS mailing lists. I don't mean there are no issues, only that the FSF has not made a statement about changing its preference for GnuTLS. >> 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. EZ> I'm sorry, but you are expecting from the Emacs development something EZ> it can never provide in its present shape and form. Tracking security EZ> issues to this degree in even a single package is a very time EZ> consuming job. Unless we have several volunteers on board taking EZ> responsibility for the various packages which Emacs supports, what you EZ> seem to want is nothing more than a pipe dream. I don't see any such EZ> volunteers; in fact, I don't even see a single one. If we had such an EZ> individual, my year-old port would have been replaced by newer ones EZ> already. (Of course, the Windows build in GnuTLS is regularly broken, EZ> so it's not really easy, either.) Until that changes, all this talk EZ> is just a huge waste of energy. EZ> If you think this kind of effort is possible, how about if you present EZ> a complete realistic plan for having a secure Emacs, name individuals EZ> who would test the releases of those packages for security issues, and EZ> make sure any problems that are detected are promptly fixed on all EZ> platforms we support, etc.? Otherwise, let's just stop these endless EZ> discussions and admit that we don't have the resources to live up to EZ> it. I'm trying to get the work started by first and foremost deciding if Emacs as a project wants to do this at all. This is a decision for the maintainers and you've voted against it on emacs-devel, so let's see what the vote count is and what the maintainers say. If the maintainers are OK with this direction, I will start working on automating the builds (which will need your help initially, if you're willing, to replicate your build process), asking for volunteers, and packaging the libraries. I don't have a 5-year plan but hope to get far enough to make it something sustainable. Ted