unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: emacs-devel@gnu.org
Subject: Re: Wherein I argue for the inclusion of libnettle in Emacs 24.5
Date: Wed, 05 Feb 2014 17:13:29 +0900	[thread overview]
Message-ID: <874n4e3rkm.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <87y51qcace.fsf@lifelogs.com>

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.



  reply	other threads:[~2014-02-05  8:13 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-03 22:36 Wherein I argue for the inclusion of libnettle in Emacs 24.5 Lars Ingebrigtsen
2014-02-04  3:21 ` Stefan Monnier
2014-02-04 13:07   ` Ted Zlatanov
2014-02-04 14:44     ` Stephen J. Turnbull
2014-02-04 18:36       ` Ted Zlatanov
2014-02-04 22:44   ` Lars Ingebrigtsen
2014-02-05  2:28     ` Stefan Monnier
2014-02-05  2:39       ` Lars Ingebrigtsen
2014-02-05  7:00       ` Ted Zlatanov
2014-02-05  8:13         ` Stephen J. Turnbull [this message]
2014-02-05 13:41           ` Ted Zlatanov
2014-02-05 15:50             ` andres.ramirez
2014-02-05 17:00             ` chad
2014-02-05 18:55               ` Ted Zlatanov
2014-02-06  5:03             ` Stephen J. Turnbull
2014-02-06 11:49               ` Ted Zlatanov
2014-02-06 13:03                 ` Stefan Monnier
2014-02-06 14:28                   ` Ted Zlatanov
2014-02-06 15:05                 ` Stephen J. Turnbull
2014-02-06 15:54                   ` Ted Zlatanov
2014-02-07  2:06                     ` Stephen J. Turnbull
2014-02-07  6:51                       ` David Kastrup
2014-02-07  7:15                         ` Stephen J. Turnbull
2014-02-07  8:53                           ` David Kastrup
2014-02-07 10:00                             ` Stephen J. Turnbull
2014-02-07 10:49                               ` David Kastrup
2014-02-07 20:43                                 ` Stephen J. Turnbull
2014-02-07 21:42                                   ` Ted Zlatanov
2014-02-07 22:23                                     ` Stephen J. Turnbull
2014-02-07 15:30                               ` Ted Zlatanov
2014-02-07  9:07                     ` Daiki Ueno
2014-02-07 11:54                       ` Ted Zlatanov
2014-02-08  8:11                         ` Daiki Ueno
2014-02-08 16:59                           ` Ted Zlatanov
2014-02-05  8:19         ` Daiki Ueno
2014-02-04 13:10 ` Ted Zlatanov
2014-02-04 16:27   ` Paul Eggert
2014-02-04 18:32     ` Ted Zlatanov
2014-02-04 19:04       ` Paul Eggert
2014-02-04 20:11         ` Ted Zlatanov
2014-02-04 21:46           ` Paul Eggert
2014-02-04 22:44             ` Ted Zlatanov
2014-02-04 22:36           ` Lars Ingebrigtsen
2014-02-05  5:11             ` Daiki Ueno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874n4e3rkm.fsf@uwakimon.sk.tsukuba.ac.jp \
    --to=stephen@xemacs.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).