From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.bugs Subject: bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely, bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely Date: Wed, 23 Oct 2013 15:49:46 -0400 Message-ID: <21096.10330.57872.224325@consult.pretender> References: <21089.32240.198931.971000@consult.pretender> <87fvrun1pw.fsf@flea.lifelogs.com> <21093.32992.278229.646703@consult.pretender> <877gd5mo5x.fsf@flea.lifelogs.com> <21094.39055.449629.706850@consult.pretender> <21094.40085.664080.69561@consult.pretender> <21094.52645.645440.977584@consult.pretender> <21094.64459.131668.849138@consult.pretender> <21095.19949.639350.970770@consult.pretender> <83wql4hvam.fsf@gnu.org> <21096.920.835718.562924@consult.pretender> <83hac7j2a2.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1382557873 14759 80.91.229.3 (23 Oct 2013 19:51:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Oct 2013 19:51:13 +0000 (UTC) Cc: tzz@lifelogs.com, emacs@kosowsky.org, 15648@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 23 21:51:16 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 1VZ4SZ-0006Ks-Pj for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Oct 2013 21:51:16 +0200 Original-Received: from localhost ([::1]:51223 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZ4SZ-0004OI-Bg for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Oct 2013 15:51:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZ4SR-0004OC-JM for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 15:51:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZ4SM-0004Ad-Mj for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 15:51:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZ4SM-0004AZ-J0 for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 15:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VZ4SL-0000N4-U1 for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 15:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Oct 2013 19:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15648 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 15648-submit@debbugs.gnu.org id=B15648.13825578261368 (code B ref 15648); Wed, 23 Oct 2013 19:51:01 +0000 Original-Received: (at 15648) by debbugs.gnu.org; 23 Oct 2013 19:50:26 +0000 Original-Received: from localhost ([127.0.0.1]:38686 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZ4Rm-0000Lz-7P for submit@debbugs.gnu.org; Wed, 23 Oct 2013 15:50:26 -0400 Original-Received: from vms173003pub.verizon.net ([206.46.173.3]:56672) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZ4Ri-0000Ll-BW for 15648@debbugs.gnu.org; Wed, 23 Oct 2013 15:50:23 -0400 Original-Received: from consult.pretender ([unknown] [72.93.211.25]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MV50009F0EZLR90@vms173003.mailsrvcs.net> for 15648@debbugs.gnu.org; Wed, 23 Oct 2013 14:49:58 -0500 (CDT) Original-Received: from consult.pretender (consult.pretender [127.0.0.1]) by consult.pretender (8.14.4/8.14.4) with ESMTP id r9NJnkVj028081; Wed, 23 Oct 2013 15:49:46 -0400 In-reply-to: <83hac7j2a2.fsf@gnu.org> X-Mailer: VM 8.2.0b under 23.1.1 (i386-redhat-linux-gnu) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.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:79553 Archived-At: Eli Zaretskii wrote at about 21:00:21 +0300 on Wednesday, October 23, 2013: > > From: > > Date: Wed, 23 Oct 2013 13:12:56 -0400 > > Cc: emacs@kosowsky.org, tzz@lifelogs.com, 15648@debbugs.gnu.org > > > > 4. This small patch to gnutls.el will fix the problem by expanding the > > file name to a full, valid path: > > Sorry, but I cannot accept this. There's absolutely no reason to run > the file through expand-file-name at that place. There is a *great* reason to add expand-file-name *any* time you pass a file name or path to external C-code that references the file system. This is necessary (and should be best or even required practice) since Emacs by design may include various filehandlers (like cygwin-mount) that internally translate path names before accessing the file system while external C-code has no way of knowing that the path names need transformation. This is particularly important since the Emacs filehandlers may be turned on and off or changed at will or dynamically and the C-code can't possibly know that, so it can't possibly know how and when to perform the required file handling operations to access the file system. Thus, I would argue that it is best practice to use expand-file-name whenever a file path is passed from Emacs lisp to C-code to ensure that a system valid (absolute) path is ultimately passed to the file system independent of how Emacs may be translating paths internally. > More importantly, there's no reason to believe this is the only > place where the same problem could surface. There is a wonderful reason to so believe since It is the only place that gnutls-trustfiles is referenced... hence, it is the natural place to fix it. It's pretty simple. You really have only 3 choices: 1. Only allow path names in gnutls-trustfiles that are native and understandable as-is to the machine. In particular, this would mean deleting the default gnutls-turstfiles cgywin entry since it is written relative to cygwin root which is not known to the C-code or to the system. Note that making the path hard-wired absolute wouldn't work for cygwin since while cygwin root is typically C:\cygwin, it need not be.. Of course, deleting the cygwin entry is reasonable, if you don't care about supporting cygwin by default 2. Add my patch or a similar to ensure that a valid path is always passed to the C-code -- whether one is using cygwin mount or any other code that changes how Emacs translates path names. This approach is simple and non-harmful, should always work, and in general protects the C-code from being passed a non-valid path. 3. Modify the C-code to include cygwin-mount type functionality so that the cygwin root is prepended to cygwin style path names. This is probably not an easy or practical solution since it requires changing the compiled C-library with calls to various cygwin functions and libraries. Also, it would only work for the file handler modifications of cygwin-mount and not to other possible file handlers -- thus modifying the C-code would be brittle, non-general, and non-portable. Leaving it as-is shouldn't be an acceptable solution since without cygwin-mount, the cygwin entry is meaningless and is *never* used -- so it's wasteful at best and confusing or crash-inducing at worst. Even worse, with cygwin-mount, it causes a crash of the entire Emacs process. So, this is a BUG in the Emacs code -- it needs to be fixed! If you don't like my fix, then feel free to find another... Of course, there is still arguably a bug in the C-code since passing an invalid path to the gnutls-boot C-code should not cause the entire Emacs process to crash. This bug should be easily reproducible by passing a cygwin path to gnutls-boot under Windows > > > Windows supports Unix-style file names. The problem is that the file > > > "/usr/ssl/certs/ca-bundle.crt" cannot be found by starting from the > > > root directory of the current drive. > > > > The above proposed patch would fix that problem. > > Only by sheer luck. Really? I can pretty much guarantee it will always fix the problem for gnutls.el since there is no other reference to gnutls-trustfiles. The alternative fix is to delete the cygwin entry.