From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH RFC] GnuTLS: Support TOFU certificate checking. Date: Wed, 08 Oct 2014 17:19:12 +0200 Message-ID: <87tx3emvwv.fsf@alrua-karlstad.karlstad.toke.dk> References: <1412716565-7786-1-git-send-email-toke@toke.dk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1412781591 17501 80.91.229.3 (8 Oct 2014 15:19:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Oct 2014 15:19:51 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 08 17:19:46 2014 Return-path: Envelope-to: ged-emacs-devel@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 1Xbt1m-0007IV-Di for ged-emacs-devel@m.gmane.org; Wed, 08 Oct 2014 17:19:46 +0200 Original-Received: from localhost ([::1]:36865 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xbt1m-0000Om-0z for ged-emacs-devel@m.gmane.org; Wed, 08 Oct 2014 11:19:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xbt1T-0000MT-TK for emacs-devel@gnu.org; Wed, 08 Oct 2014 11:19:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xbt1M-0001Gk-6o for emacs-devel@gnu.org; Wed, 08 Oct 2014 11:19:27 -0400 Original-Received: from mail2.tohojo.dk ([77.235.48.147]:50697) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xbt1L-0001GZ-U0 for emacs-devel@gnu.org; Wed, 08 Oct 2014 11:19:20 -0400 X-Virus-Scanned: amavisd-new at mail2.tohojo.dk Original-Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id 9D17B1B538F; Wed, 8 Oct 2014 17:19:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1412781488; bh=u/CK+jGvAUTWBSvu+i/nSc+TxR4/4XUeF73YilWG/ps=; h=From:To:Subject:References:Date:In-Reply-To; b=k0qGdsfRX8yt4k1s/7TQZ44lv8AeLp761/HzF1aj0ehdINE5HZj699q7mWaVfH2e3 Eb3ikK96MyDtPOWFdqv5wA16En1KyIyWroiJaXIQWhZoNUml31lKVWhb1IMFZslVsv Lwbdo7KeLJIW50oTXqLD4RkKhOQ4D5031Ie68p4s= In-Reply-To: (Ted Zlatanov's message of "Wed, 08 Oct 2014 10:52:33 -0400") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.235.48.147 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175140 Archived-At: Ted Zlatanov writes: > Wonderful work, thank you! Glad you think so :) > You should check in the autoconf script whether > `gnutls_verify_stored_pubkey' is available. It's a fairly new function > and we have to support older versions of GnuTLS without it. Right; will look into that. > I like the simplicity of it. It would be nice to do this inside Emacs > itself (it's OK if it requires some kind of `emacs --batch' call, > doesn't have to be immediate). Either way, the errors should tell us > specifically what to run from the command line in these two cases: I have an updated version where I split out the parameters into :tofu-strict and :tofu-auto, where the latter will automatically add a certificate that hasn't been seen before (and fail on mismatch only). This might be more suitable to have turned out by default. Removing things from the key store has to be done manually, though; but that goes for gnutls-cli as well (and even for ssh). > error ("No TOFU trust entry found for hostname \"%s\" and service \"%s\"", c_hostname, c_service); > error ("TOFU trust MISMATCH for hostname \"%s\" and service \"%s\"", c_hostname, c_service); Will update the messages to be more helpful. > I think so. But Emacs creates a Emacs-specific homedir for the GnuPG > keychain, for verification of the package archives, in > `~/.emacs.d/gnupg' which is an equally valid approach. So I don't have > a strong opinion. > > What's the drawback of having a dedicated Emacs store? Do any other > programs besides `gnutls-cli` use the global GnuTLS store? Well, any programs that use gnutls and pass NULL as the trust store will share the site default. Using this also has the nice side effect of not having to come up with a portable way to find a suitable file name (I'm sure this is solved elsewhere in the emacs code but it saved me from going looking ;)). > If you can submit a bug with this, it would be wonderful. I've been > meaning to get rid of the `cl-mapcan' call anyhow. I've submitted a bug. > I think that's pretty tricky with GnuTLS because it expects all the > validations to be C callbacks and just hands off the connection at the > end. You're not supposed to interact with the session during the > validation, IIUC. So it will probably require two attempts. Noted. I checked what gnutls-cli does (by way of packet dumps), and it seems to keep the connection open, presumably in the middle of the handshake, while waiting for the user to decide whether to trust it. So presumably something similar could be done by Emacs, and I think it's more a matter of whether or not it's possible to call back up into lisp from this part of the code. > Yes, that would be nice and clean. They can simply be attached as > symbol properties to the error. Maybe you can adjust > `gnutls_make_error'? I will look into it. I'm out of time to hack on this for a while, so for now I'll just resubmit the patch with the changes noted above, and then return to this at a later date (heh, famous last words). -Toke