[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Wherein I argue for the inclusion of libnettle in Emacs 24.5

From: andres . ramirez
Subject: Re: Wherein I argue for the inclusion of libnettle in Emacs 24.5
Date: Wed, 05 Feb 2014 10:50:49 -0500
User-agent: SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Goj┼Ź) APEL/10.8 EasyPG/1.0.0 Emacs/24.3 (x86_64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO)

At Wed, 05 Feb 2014 08:41:31 -0500,
Ted Zlatanov wrote:
> On Wed, 05 Feb 2014 17:13:29 +0900 "Stephen J. Turnbull" <address@hidden> 
> wrote: 
> On Wed, 05 Feb 2014 17:19:13 +0900 Daiki Ueno <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]