From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#10904: 24.0.93; Infinite loop in GnuTLS code during Gnus nnimap-initiated SSL handshake Date: Fri, 05 Feb 2016 18:26:46 +1100 Message-ID: <87powbzkg9.fsf@gnus.org> References: <87haxk3dce.fsf@lifelogs.com> <87hax6wakn.fsf@lifelogs.com> <87sjgdoi43.fsf@lifelogs.com> <8762d7kdk6.fsf@lifelogs.com> <878uif8p0f.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1454657306 23967 80.91.229.3 (5 Feb 2016 07:28:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Feb 2016 07:28:26 +0000 (UTC) Cc: Thomas Fitzsimmons To: 10904@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 05 08:28:15 2016 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 1aRaoP-0002U0-3e for geb-bug-gnu-emacs@m.gmane.org; Fri, 05 Feb 2016 08:28:13 +0100 Original-Received: from localhost ([::1]:46464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRaoO-0000wo-68 for geb-bug-gnu-emacs@m.gmane.org; Fri, 05 Feb 2016 02:28:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58574) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRaoJ-0000vU-Cm for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 02:28:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRaoE-0006ga-DT for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 02:28:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52384) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRaoE-0006gW-9i for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 02:28:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aRaoE-000759-5A for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 02:28:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Feb 2016 07:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10904-submit@debbugs.gnu.org id=B10904.145465724227160 (code B ref 10904); Fri, 05 Feb 2016 07:28:02 +0000 Original-Received: (at 10904) by debbugs.gnu.org; 5 Feb 2016 07:27:22 +0000 Original-Received: from localhost ([127.0.0.1]:60969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRanZ-00073z-P4 for submit@debbugs.gnu.org; Fri, 05 Feb 2016 02:27:22 -0500 Original-Received: from hermes.netfonds.no ([80.91.224.195]:55663) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRanU-00073n-EI for 10904@debbugs.gnu.org; Fri, 05 Feb 2016 02:27:19 -0500 Original-Received: from cpe-60-225-211-161.nsw.bigpond.net.au ([60.225.211.161] helo=mouse) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1aRan5-0005Px-3T; Fri, 05 Feb 2016 08:26:51 +0100 In-Reply-To: <878uif8p0f.fsf@lifelogs.com> (Ted Zlatanov's message of "Wed, 10 Dec 2014 11:10:08 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-MailScanner-ID: 1aRan5-0005Px-3T MailScanner-NULL-Check: 1455262012.51732@ZLJnzD5DxW3Hz/JPCIDMFg X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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:112470 Archived-At: Ted Zlatanov writes: > On Mon, 08 Dec 2014 21:06:21 +0100 Lars Magne Ingebrigtsen wrote: > > LMI> Ted Zlatanov writes: >>> I plan to follow Nikos' advice here: >>> >>> http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/6017 >>> >>> so we'll drop from NORMAL to PERFORMANCE, basically, if the user >>> approves. After the 24.1 release I'll look at this. > > LMI> Would it make sense to just default to PERFORMANCE now that we have the > LMI> NSM? > > The default priority string should correspond to the medium > `network-security-level' so yes, I think so. But I really think those > two should be bound closer together, as I mentioned. Yeah... running with PERFORMANCE by default is perhaps hubris. :-) But how would we do this within the open-network-stream/nsm framework... Basically, with NORMAL the tls negotiation will fail. It would be nice if we could then let the NSM query the user for whether they want to lower the security to PERFORMANCE and reconnect. But that doesn't quite fit the way all of this is structured. If the user says "yes, go ahead and lower security", then the NSM will have to, er, bind something, and then call open-network-stream all over again? Sort of? That's probably possible, but it may require some extensive tinkering with how `nsm-verify-connection' is called... or with how open-network-stream structures the call to NSM. *time passes* Hm! Perhaps it won't be that difficult or invasive. This is how this is called: (defun network-stream-open-tls (name buffer host service parameters) (with-current-buffer buffer (let* ((start (point-max)) (stream (if (gnutls-available-p) (open-gnutls-stream name buffer host service (plist-get parameters :nowait)) (open-tls-stream name buffer host service))) (eoc (plist-get parameters :end-of-command))) ;; Check certificate validity etc. (when (and (gnutls-available-p) stream) (setq stream (nsm-verify-connection stream host service))) So what happens here is that stream will be nil or dead from open-gnutls-stream. In that case, it could call nsm-verify-connection with some special parameters, have it prompt, and then reconnect if the user says "yes"... Hm. But then those stores parameters should be used the next time in network-stream, and it doesn't have access to those stored parameters. Gah. This stuff is hard. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no