From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/83847 Path: news.gmane.org!not-for-mail From: Vincent Bernat Newsgroups: gmane.emacs.gnus.general Subject: Re: Builtin GnuTLS support and certificate verification Date: Mon, 04 Nov 2013 20:54:26 +0100 Message-ID: References: <87iowbt5dq.fsf@guybrush.luffy.cx> <878ux782na.fsf@dex.adm.naquadah.org> <874n7uu2gg.fsf@guybrush.luffy.cx> <87txftsnub.fsf@flea.lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1383594923 5392 80.91.229.3 (4 Nov 2013 19:55:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Nov 2013 19:55:23 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M32103@lists.math.uh.edu Mon Nov 04 20:55:27 2013 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VdQFC-0004LM-Vv for ding-account@gmane.org; Mon, 04 Nov 2013 20:55:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1VdQEL-000479-Te; Mon, 04 Nov 2013 13:54:33 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1VdQEK-00046z-Pv for ding@lists.math.uh.edu; Mon, 04 Nov 2013 13:54:32 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1VdQEJ-00023w-8I for ding@lists.math.uh.edu; Mon, 04 Nov 2013 13:54:32 -0600 Original-Received: from bart.luffy.cx ([78.47.78.131]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1VdQEH-0000ur-0L for ding@gnus.org; Mon, 04 Nov 2013 20:54:29 +0100 Original-Received: from bart.luffy.cx (localhost [127.0.0.1]) by bart.luffy.cx (Postfix) with ESMTP id 60C16141F7 for ; Mon, 4 Nov 2013 20:54:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=luffy.cx; h=from:to:subject :references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=postfix; bh=KDThmQexg glxlVPDn18Qh2dof0M=; b=Os2nTSzi3nRcieKm8YaDzNPO6bH6h3EQDUhNO5Ofc wsWNY0daE3aK0ub+9pokq6GJRIdUOx1SCEawNyyFypFf8dkv3YeUOLuP58uGUet+ y7Y7hPo0eMrU7wig+YK7EVCPmaWluxEaa4CldfM/huFNl7UYehH2HDu3zU/xXcRv pc= DomainKey-Signature: a=rsa-sha1; c=simple; d=luffy.cx; h=from:to:subject :references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=postfix; b=FJn +VI9Gu3FTEah0BfA9STiS5kd2D4jumB3shEheBO77D5xWMtLh2vZB17ENtLWkppF 59JEX5y84lZUnBFLH1vBE4AGL/z6QICWLqTjhA4Zy8OrL1BZ2I4IsejZLtDsMgQ6 9XxJd5Z8BFRjlznkGGhSl7ydQV6/nq9C4xrLdW50= Original-Received: from neo.luffy.cx (unknown [IPv6:2a01:e34:ec6d:710:218:f3ff:fe03:4e06]) by bart.luffy.cx (Postfix) with ESMTPS id 22FDE14063 for ; Mon, 4 Nov 2013 20:54:28 +0100 (CET) Original-Received: by neo.luffy.cx (Postfix, from userid 500) id E6BC821A; Mon, 4 Nov 2013 20:54:26 +0100 (CET) In-Reply-To: <87txftsnub.fsf@flea.lifelogs.com> (Ted Zlatanov's message of "Sun, 03 Nov 2013 06:53:48 -0500") User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) X-Spam-Score: -2.0 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:83847 Archived-At: =E2=9D=A6 3 novembre 2013 12:53 CET, Ted Zlatanov =C2= =A0: > `verify-error', however, is missing from the docstring of > gnutls.c:gnutls-boot and there's just a commented-out line in the > function: > > /* Lisp_Object verify_error; */ > > and the verification code, as you observed, does all the peer > verification based on `verify-hostname-error'. I think this is my > error; this code: > > if (peer_verification !=3D 0) > { > if (NILP (verify_hostname_error)) > GNUTLS_LOG2 (1, max_log_level, "certificate validation failed:", > c_hostname); > else > { > emacs_gnutls_deinit (proc); > error ("Certificate validation failed %s, verification code %d", > c_hostname, peer_verification); > } > } > > should have been using `verify_error' instead. > > Could you double-check my investigation and confirm? If you agree, I > will make the change and update the bug report. I agree with you but I find odd to have two verification algorithms. I don't see the point of verifying the hostname if the certificate is invalid on some other points and I don't see the point of not verifying the hostname. I mean, if you accept any valid certificate, it is trivial for me to present you with the certificate of my website. If you accept any invalid certificate with the right hostname, it is also trivial for me to build a self-signed certificate with the right hostname. Now, if `:trustfiles` is set to a non standard location, the first case may makes sense: I don't check the hostname but the certificate should only be valid if signed by some other certificate that I specify exactly. However, in which case could this be useful? Either you have signed yourself the certificate and it is trivial to set the appropriate name or you bought it and I could buy a certificate from the same shop with another name. So, for me, there should be only one verification algorithm. We are not in the ideal case for this because we only have one algorithm but its name does not exactly describe it. Maybe you could just alias verify-error and verify-hostname-error and say in the documentation that they do the same and that verify-hostname-error will be removed at some point? --=20 printk("Illegal format on cdrom. Pester manufacturer.\n");=20 2.2.16 /usr/src/linux/fs/isofs/inode.c