From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Wherein I argue for the inclusion of libnettle in Emacs 24.5 Date: Fri, 07 Feb 2014 11:06:16 +0900 Message-ID: <87r47fn0br.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87ha8f3jt1.fsf@building.gnus.org> <87ppn2qz0f.fsf@building.gnus.org> <87y51qcace.fsf@lifelogs.com> <874n4e3rkm.fsf@uwakimon.sk.tsukuba.ac.jp> <87txcdd6d0.fsf@lifelogs.com> <87wqh8n877.fsf@uwakimon.sk.tsukuba.ac.jp> <87lhxocvfq.fsf@lifelogs.com> <87sirwmgd9.fsf@uwakimon.sk.tsukuba.ac.jp> <87d2j0ck3q.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1391738860 9796 80.91.229.3 (7 Feb 2014 02:07:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Feb 2014 02:07:40 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 07 03:07:44 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 1WBar0-0007FS-Tb for ged-emacs-devel@m.gmane.org; Fri, 07 Feb 2014 03:07:43 +0100 Original-Received: from localhost ([::1]:39086 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBar0-0005nh-Dx for ged-emacs-devel@m.gmane.org; Thu, 06 Feb 2014 21:07:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBaqq-0005nb-Be for emacs-devel@gnu.org; Thu, 06 Feb 2014 21:07:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WBaqj-0008U3-2u for emacs-devel@gnu.org; Thu, 06 Feb 2014 21:07:32 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:60700) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBaqi-000867-Iu for emacs-devel@gnu.org; Thu, 06 Feb 2014 21:07:25 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 440A097069B for ; Fri, 7 Feb 2014 11:06:16 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 35BF51A2794; Fri, 7 Feb 2014 11:06:16 +0900 (JST) In-Reply-To: <87d2j0ck3q.fsf@lifelogs.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:169448 Archived-At: Ted Zlatanov writes: > What do you think happens when you open a .gpg file using GnuPG > externally, even disregarding the OS channels traveled? That data is > certainly not safe from defadvice. Of course it isn't. It's not my claim that GnuPG is clearly more secure than doing it internally, it's that doing it internally can only be more secure if GnuPG is more buggy than your code + user code, and I find that highly unlikely. > into a buffer. This is *not* saying the EPA/EPG design is bad, only > that Emacs as a whole could use a way to hide "data not intended for > direct user inspection" better, and provide for a "tainting" trace of > data (to use the Perl term). Sure, it could use those facilities, but it doesn't have them, and providing them will require completely redesigning internals. Note that this is not do deny that you can get that security for *specific* functions using libnettle *if you write them in C*. What I'm saying is that exposing them to Lisp means exposing them to Lisp, and as Emacs is currently composed, that's a security oops assuming an attack with enough access to pop up a Trojan Horse password havester. > OK then, let's hypothesize. I don't think the presence of these > primitives will make the situation worse by flooding us with badly > implemented crypto. I don't think it will be a flood. I think that it is a hanging noose that will strangle a trickle of users every day for the indefinite future, and I don't see a corresponding benefit to outweigh that and the issues that Stefan raises. > Realistically speaking, attacks against Emacs are extremely unlikely > unless specific people are targeted. Exactly.