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: Wed, 05 Feb 2014 08:41:31 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87txcdd6d0.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> 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 1391607710 17597 80.91.229.3 (5 Feb 2014 13:41:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Feb 2014 13:41:50 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 05 14:41:59 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 1WB2jl-0001n5-BN for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 14:41:57 +0100 Original-Received: from localhost ([::1]:59271 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB2jk-0001JI-Vt for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 08:41:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38610) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB2jd-0001J6-3S for emacs-devel@gnu.org; Wed, 05 Feb 2014 08:41:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WB2jX-0000Zi-Ue for emacs-devel@gnu.org; Wed, 05 Feb 2014 08:41:49 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:54662) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB2jX-0000Zc-K7 for emacs-devel@gnu.org; Wed, 05 Feb 2014 08:41:43 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WB2jU-0001as-NY for emacs-devel@gnu.org; Wed, 05 Feb 2014 14:41:40 +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 ; Wed, 05 Feb 2014 14:41:40 +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 ; Wed, 05 Feb 2014 14:41:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 103 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:bYXo6JrB1wUvYHutyZp2FrLSxuc= 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:169410 Archived-At: On Wed, 05 Feb 2014 17:13:29 +0900 "Stephen J. Turnbull" wrote: On Wed, 05 Feb 2014 17:19:13 +0900 Daiki Ueno wrote: SJT> Ted Zlatanov writes: >> Right. Shelling out SJT> Fine point: no need for a shell, and it's almost certainly preferable SJT> 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. SJT> Obviously not perfect, since at least one person in the world doesn't SJT> get it. Nevertheless, the GPG developers apparently think it does SJT> make good sense, since they've made a point of making it difficult to SJT> do otherwise. DU> At least it works at acceptable performance now. It's not acceptable to me, but then again I'm not a crypto/security-expert. >> Blindly entering your passphrase in an anonymous popup that says >> it's from the GnuPG agent is how things are done. SJT> Not relevant in the sense that it could be done with an anonymous SJT> popup that says it's from Emacs, too. The minibuffer is much harder to fake than a popup. Furthermore, you don't know *which* passphrase is being requested, so at the very least it can be annoying. Oh, I know, we'll add --with-pinentry-title and --with-pinentry-message flags. Christ. DU> This could be fixed. Sounds definitely easier than importing plenty of DU> crypto primitives from a C library. It doesn't have to be an exclusive choice, and I'm not asking anyone to do the work on either side. >> Trusting loosely coupled components is standard industry practice. SJT> Trust and coupling are not in any particular relationship. Viz. the SJT> fundamental design of Qmail and Postfix, which are two MTAs designed SJT> by acknowledged security experts. qmail and Postfix are system applications that run as daemons. Completely different from Emacs. Emacs is more like Firefox or Chrome with their embedded Javascript engines and layout renderers, as Lars pointed out. Those applications tend to use the platform's keychain facilities and do the crypto work internally. DU> Didn't I post a link to the idea of this loose coupling? It is mainly DU> for security reasons. For example, there's usually a limit of secure DU> memory and it makes sense to do all the secret key operation in a DU> minimal core (gpg-agent) to utilize it. DU> I don't think you can provide the same level of security using DU> encryption primitives within Emacs. Not currently, sure. But at this point you're the one arguing hypotheticals. >> 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. SJT> Stupid, no, but there's a lot of evidence that they are ignorant SJT> (including many developers incorporating security features in their SJT> products), and that even experienced experts are oversight- and even SJT> mistake-prone in this area. Do you claim that that evidence is no SJT> longer relevant? I don't think you can justify taking away the freedom to choose because it might be misused. DU> I don't get it. Are there any platforms where Emacs work, while GPG DU> does not? Please don't turn my point into a debate about why can't I "just use GnuPG." I'm asking to have a choice. It doesn't mean I don't understand what EPA/EPG and GnuPG offer, or that I don't like them, or that I don't use them. >> Is that how experts with a crypto/security background do it? SJT> Some of them (the GPG developers) do, for sure. DU> Better than letting you write encryption code for me. I plan to write integration code mostly, which is not as risky. But you make a good point: *you're* the only one writing such code for Emacs users. Could you be biased in favor of your own code? DU> Case study (sorry Jose): DU> https://lists.gnu.org/archive/html/bug-recutils/2012-04/msg00001.html DU> I can easily imagine you will make similar (or more serious) mistakes DU> here and there, once crypto primitives are available. If only there were experts among us and I would allow my code to be reviewed! Ted