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: Wed, 05 Feb 2014 17:13:29 +0900 Message-ID: <874n4e3rkm.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87ha8f3jt1.fsf@building.gnus.org> <87ppn2qz0f.fsf@building.gnus.org> <87y51qcace.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 1391588091 10320 80.91.229.3 (5 Feb 2014 08:14:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Feb 2014 08:14:51 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 05 09:14:54 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 1WAxdG-0003wr-Mi for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 09:14:54 +0100 Original-Received: from localhost ([::1]:57870 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAxdG-0005ks-7Y for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 03:14:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAxd6-0005kd-Vf for emacs-devel@gnu.org; Wed, 05 Feb 2014 03:14:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WAxcz-0004Zf-MZ for emacs-devel@gnu.org; Wed, 05 Feb 2014 03:14:44 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:34776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAxcz-0004Gx-5e for emacs-devel@gnu.org; Wed, 05 Feb 2014 03:14:37 -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 29997970A0A for ; Wed, 5 Feb 2014 17:13:29 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 1BF191A2794; Wed, 5 Feb 2014 17:13:29 +0900 (JST) In-Reply-To: <87y51qcace.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:169407 Archived-At: Ted Zlatanov writes: > Right. Shelling out Fine point: no need for a shell, and it's almost certainly preferable not use a shell. > to an external binary every time you want to verify a package's > signature or want to encrypt/decrypt/sign data makes perfect sense. Obviously not perfect, since at least one person in the world doesn't get it. Nevertheless, the GPG developers apparently think it does make good sense, since they've made a point of making it difficult to do otherwise. > Blindly entering your passphrase in an anonymous popup that says > it's from the GnuPG agent is how things are done. Not relevant in the sense that it could be done with an anonymous popup that says it's from Emacs, too. > Trusting loosely coupled components is standard industry practice. Trust and coupling are not in any particular relationship. Viz. the fundamental design of Qmail and Postfix, which are two MTAs designed by acknowledged security experts. > Forcing users to do all of that, or "no encryption for you" is for > their own good, on every platform where Emacs runs, from Android to > W32 to Mac OS X to many flavors of Unix. Users are just too stupid > to decide these things on their own. Stupid, no, but there's a lot of evidence that they are ignorant (including many developers incorporating security features in their products), and that even experienced experts are oversight- and even mistake-prone in this area. Do you claim that that evidence is no longer relevant? > Is that how experts with a crypto/security background do it? Some of them (the GPG developers) do, for sure. To summarize, I just don't find your arguments that GPG is a poor solution from the security viewpoint plausible. OTOH, libnettle would be a neat feature, but I personally don't find a compelling necessity for it. larsi's use case seems pretty strong to me, but not enough so that I'd go against Stefan's gut feeling on the matter.