From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Wherein I argue for the inclusion of libnettle in Emacs 24.5 Date: Fri, 07 Feb 2014 06:54:39 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87y51nb0jk.fsf@lifelogs.com> 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> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1391774096 30177 80.91.229.3 (7 Feb 2014 11:54:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Feb 2014 11:54:56 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 07 12:55:02 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 1WBk1M-0007OP-Iw for ged-emacs-devel@m.gmane.org; Fri, 07 Feb 2014 12:55:00 +0100 Original-Received: from localhost ([::1]:40994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBk1M-0004Hs-8o for ged-emacs-devel@m.gmane.org; Fri, 07 Feb 2014 06:55:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBk1F-0004Fm-LR for emacs-devel@gnu.org; Fri, 07 Feb 2014 06:54:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WBk1B-0001ED-HC for emacs-devel@gnu.org; Fri, 07 Feb 2014 06:54:53 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:41454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBk1B-0001E8-7N for emacs-devel@gnu.org; Fri, 07 Feb 2014 06:54:49 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WBk19-0007D4-JX for emacs-devel@gnu.org; Fri, 07 Feb 2014 12:54:47 +0100 Original-Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Feb 2014 12:54:47 +0100 Original-Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Feb 2014 12:54:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 59 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:W/u/BVwKS5e7fwY5pP96/8IElmI= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:169459 Archived-At: On Fri, 07 Feb 2014 18:07:35 +0900 Daiki Ueno wrote: DU> 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. DU> Didn't I ever say: DU> - Once an attacker successfully takes over your desktop session, he can DU> do almost everything. We can't do much on that situation. Why don't DU> you lock the screen before leaving? We could at least try to process data in a place where ELisp can't access it. DU> - More possible threat is inspecting persistent data (e.g. core files on DU> a disk attached to a stolen note PC). GnuPG is designed to be secure DU> against this, using "secure core". I don't agree with the EPA/EPG coupling to GnuPG but admire the design of both sides. GnuPG is a great program that, due to the client/agent design, is hard to use securely as an API. As proof, consider the Java libraries to implement OpenPGP internally (BouncyCastle). Similar situation in Go (http://godoc.org/code.google.com/p/go.crypto/openpgp). Is Emacs so different from those platforms, given applications like Gnus and Magit and eww? DU> - On the other hand, Emacs copies small strings around. If passwords DU> (normally not too long) are managed poorly in Emacs, they might appear DU> repeatedly in a core file, when it crashes. Right, regardless of EPA/EPG's behavior, you *still* need passwords in the clear to open an IMAP connection, for instance. I feel that, unless we wish to blame the user for not locking their desktop, Emacs should at least try to protect such passwords in its own "secure core." It's surely possible and, I honestly believe, a worthy goal. I think for that goal to happen *some day* we need the crypto primitives GnuTLS/libnettle/libhogweed provide, so we don't have to write our own. >> 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). DU> Interesting. Any prior art on that area? I haven't heard the word DU> "tainting" used in that way. Isn't it for preventing untrusted data DU> being injected to, say, SQL? Here I meant it in the sense of "knowing when a data token has been touched by a Lisp function" with the assumption that Lisp code is inherently unsafe. (Perl's "taint" traces data obtained externally. It's remarkable because it imposes some security on top of a very liberal language, a lot like Lisp in fact. See http://perldoc.perl.org/perlsec.html for further details.) Ted