From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/60128 Path: news.gmane.org!not-for-mail From: Carl Henrik Lunde Newsgroups: gmane.emacs.gnus.general Subject: Re: Should open-tls-stream signal an error? Date: Fri, 08 Apr 2005 02:54:18 +0200 Message-ID: <87d5t6cclh.fsf@eon.ping.uio.no> References: <874qfphks0.fsf@zemdatav.stor.no-ip.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: sea.gmane.org 1112984467 7867 80.91.229.2 (8 Apr 2005 18:21:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 8 Apr 2005 18:21:07 +0000 (UTC) Original-X-From: ding-owner+M8654@lists.math.uh.edu Fri Apr 08 20:21:02 2005 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DJy61-0001Lo-93 for ding-account@gmane.org; Fri, 08 Apr 2005 20:20:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1DJy42-0003Zh-00; Fri, 08 Apr 2005 13:18:42 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1DJhtl-0001sv-00 for ding@lists.math.uh.edu; Thu, 07 Apr 2005 20:03:01 -0500 Original-Received: from quimby.gnus.org ([80.91.224.244]) by util2.math.uh.edu with esmtp (Exim 4.30) id 1DJhtf-0007I3-FO for ding@lists.math.uh.edu; Thu, 07 Apr 2005 20:02:55 -0500 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1DJhte-00079O-00 for ; Fri, 08 Apr 2005 03:02:54 +0200 Original-Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DJhqx-00061v-Q5 for ding@gnus.org; Fri, 08 Apr 2005 03:00:07 +0200 Original-Received: from krs-dhcp247.studby.uio.no ([129.240.119.25]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 03:00:07 +0200 Original-Received: from chlunde+gnus+ by krs-dhcp247.studby.uio.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 03:00:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: ding@gnus.org Original-Lines: 91 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: krs-dhcp247.studby.uio.no User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/22.0.50 (gnu/linux) Cancel-Lock: sha1:smt40gC4j7t6dkiNXc6Sv4ZLZkk= X-Spam-Score: -4.9 (----) Precedence: bulk Original-Sender: ding-owner@lists.math.uh.edu Xref: news.gmane.org gmane.emacs.gnus.general:60128 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:60128 --=-=-= A long time ago Magnus Henoch wrote: > open-tls-stream in tls.el returns nil on failure (gnutls-cli binary > not found, connection refused, etc). open-network-stream signals an > error when it can't connect. Is there any reason open-tls-stream > shouldn't do the same, instead of just returning nil? As nobody answered Magnus I made a patch, it seems to work like open-network-stream on errors, but it's hardly tested. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=tls-el-error.patch Content-Description: Make open-tls-stream behave like open-network-stream on error Index: tls.el =================================================================== RCS file: /usr/local/cvsroot/gnus/lisp/tls.el,v retrieving revision 7.5 diff -u -3 -b -r7.5 tls.el --- tls.el 13 Feb 2005 04:44:40 -0000 7.5 +++ tls.el 8 Apr 2005 00:33:31 -0000 @@ -78,6 +78,20 @@ :type 'regexp :group 'tls) +(defcustom tls-refused "connect: Connection refused" + "*Regular expression indicating connection refused +The default is what GNUTLS's \"gnutls-cli\" outputs." + :version "22.1" + :type 'regexp + :group 'tls) + +(defcustom tls-unresolvable "Cannot resolve " + "*Regular expression indicating unknown host name +The default is what GNUTLS's \"gnutls-cli\" outputs." + :version "22.1" + :type 'regexp + :group 'tls) + (defcustom tls-certtool-program (executable-find "certtool") "Name of GnuTLS certtool. Used by `tls-certificate-information'." @@ -138,11 +152,15 @@ service))))) response) (while (and process - (memq (process-status process) '(open run)) (save-excursion (set-buffer buffer) ;; XXX "blue moon" nntp.el bug (goto-char (point-min)) - (not (setq done (re-search-forward tls-success nil t))))) + (when (re-search-forward tls-unresolvable nil t) + (error "Cannot resolve `%s'" host)) + (when (re-search-forward tls-refused nil t) + (error "Connection to `%s' refused" host)) + (not (setq done (re-search-forward tls-success nil t)))) + (memq (process-status process) '(open run))) (accept-process-output process 1) (sit-for 1)) (message "Opening TLS connection with `%s'...%s" cmd @@ -152,6 +170,8 @@ (delete-process process)))) (message "Opening TLS connection to `%s'...%s" host (if done "done" "failed")) + (unless done + (error "Unknown error when connecting to `%s' -- is any `tls-program' installed?" host)) done)) (provide 'tls) --=-=-= One problem with this code is that the caller must clean the buffer before connection attempts, as messages matching tls-refused or tls-unresolvable may stay there between connections. I doubt open-network-stream requires that. If you don't think tls.el should have a patch like this, then the comment claiming "Usage is the same as `open-network-stream'" should be revised. Thanks for looking at this again Carl Henrik --=-=-=--