From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: andres.ramirez Newsgroups: gmane.emacs.devel Subject: Re: Wherein I argue for the inclusion of libnettle in Emacs 24.5 Date: Wed, 05 Feb 2014 10:50:49 -0500 Message-ID: <87vbwtwobq.wl%andres.ramirez@kipuamutay.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1391615495 21566 80.91.229.3 (5 Feb 2014 15:51:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Feb 2014 15:51:35 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 05 16:51: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 1WB4lJ-0002yi-VX for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 16:51:42 +0100 Original-Received: from localhost ([::1]:59897 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB4lJ-0003uO-FA for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 10:51:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41553) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB4lC-0003u1-4h for emacs-devel@gnu.org; Wed, 05 Feb 2014 10:51:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WB4l7-0004fq-GF for emacs-devel@gnu.org; Wed, 05 Feb 2014 10:51:34 -0500 Original-Received: from mail-yk0-x22b.google.com ([2607:f8b0:4002:c07::22b]:35890) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB4l7-0004fl-B3 for emacs-devel@gnu.org; Wed, 05 Feb 2014 10:51:29 -0500 Original-Received: by mail-yk0-f171.google.com with SMTP id 142so1418884ykq.2 for ; Wed, 05 Feb 2014 07:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:message-id:from:to:newsgroups:subject:in-reply-to :references:user-agent:mime-version:content-type; bh=IGq6HEcR5FL7A377ZvlTze3yVEu3JLghw2hIQ/ivYNY=; b=jvBZqyV5UHpmrBAZ/3oplhd4U5pG949gtUvEShciTAC/rEPpfJxSI2Z11GQc00KrxR /4pP6CpvyvRwB5vtY395xEW4M47ZSzTKsV/m4jeuzPTSQWzaTflGp9xwX6i7IB2xaVsA 7DbK5uz18oZ4JUadUF0kPiwYD+AWV0ltUSaZVU4Hpvm7GrHMz6O0umjIhI9k4TUDKY2m c1ApdxWk8kg9O7buxm7nFuXw7yGN2DprX3WDdZmHeYNvDIL2OlAIHYJyc1oR5LKnV3+G zc94TUvP6pdC5+sPd3Tof/oJALgaTUiBTgmxlOcARY3JkBe2s80kM9jpAGbTIT0LgmXa UlqQ== X-Received: by 10.236.41.225 with SMTP id h61mr227058yhb.152.1391615488571; Wed, 05 Feb 2014 07:51:28 -0800 (PST) Original-Received: from inka.kipu.pe.ryu.edu ([200.106.68.55]) by mx.google.com with ESMTPSA id 57sm97083522yhl.4.2014.02.05.07.51.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Feb 2014 07:51:27 -0800 (PST) Original-Newsgroups: gmane.emacs.devel In-Reply-To: <87txcdd6d0.fsf@lifelogs.com> X-Mailer: Wanderlust/2.15.9 X-Attribution: AR User-Agent: SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.3 (x86_64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4002:c07::22b 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:169412 Archived-At: At Wed, 05 Feb 2014 08:41:31 -0500, Ted Zlatanov wrote: > > 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. We have here a different use case. Sometimes. I need to work remotely (emacs on tty), The remote machine has 128 Mb of memory. After opening 30 tabs on emacs-w3m. Emacs starts to behave very slowly. Then I need to restart the emacs session (after restarting emacs gets speedy again). How am i suppose to fill up the popup remotely?. > > 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 > > > Regards