unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Daiki Ueno <ueno@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt
Date: Fri, 04 Oct 2013 09:12:34 +0900	[thread overview]
Message-ID: <874n8xrj0t.fsf-ueno@gnu.org> (raw)
In-Reply-To: <87bo36tpyt.fsf@flea.lifelogs.com> (Ted Zlatanov's message of "Thu, 03 Oct 2013 09:59:38 -0400")

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 03 Oct 2013 10:52:46 +0900 Daiki Ueno <ueno@gnu.org> wrote: 
>
> DU> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> See my earlier e-mails.  But my bigger concern is that for many users, a
>>> new GnuPG release is years in the future, so even if you justify this
>>> change, it won't help anyone quickly.  IMHO epg.el should work around
>>> this "feature" now with the --batch --passphrase-fd options that I
>>> mentioned, especially if they can work on all GnuPG versions (I haven't
>>> tested that).
>
> DU> Well, that's a design decision not to use --batch here (and probably in
> DU> GPGME).  If it used --batch, epg.el would need to know a passphrase even
> DU> if it is not needed (for example, it is already cached in gpg-agent,
> DU> encrypted with empty passphrase, etc.)  And also it would inhibit gpg
> DU> from doing other user queries until the gpg command terminates.
>
> OK, so there's no way to avoid the broken behavior in epg.el and any

Well, though you say "broken behavior in epg.el", there's clearly a
design change in GnuPG side if GnuPG 2.x behaves differently from GnuPG
1.x.

You can search on the gpg lists with something like: "gpg agent all
secret key", you will find that Werner wanted to move all the secret key
operations from gpg to gpg-agent to provide more security.  That then
ended up with that pinentry needs to be spawned by gpg-agent, not gpg.

I think most of your complaint on epg.el are user error and
misunderstanding of underlying technical concepts of GnuPG.

> fixes on the GnuPG side have to wait until a new release (and someone,
> possibly you, has to ask Werner for that fix).  Is that accurate?  It
> means we should recommend to Emacs users to use GnuPG 1.x if they want
> symmetric encryption to be usable (especially caching the passphrase).

We already recommend that.  See (info"(epa) Caching Passphrases").

GnuPG 1.x can coexists with GnuPG 2.x on a single system, and most of
distros keep both packages installable without conflict.  If you just
want to avoid the passphrase prompt, you can simply install both and epg
picks the GnuPG 1.x executable first:

(defcustom epg-gpg-program (or (executable-find "gpg")
			       (executable-find "gpg2")
			       "gpg")
  "The `gpg' executable."
  :group 'epg
  :type 'string)

>>> My question now, since we understand the problem well, is if you agree
>>> with this plan, and if so, do you need patches from me or other
>>> contributors, or will you address it yourself?  There's no urgency
>>> implied here; I am simply trying to fix this for our users by the next
>>> Emacs release.
>
> DU> Please don't.
>
> Don't what?  I asked several questions but am clearly waiting for your
> guidance.

I mean, don't add a workaround using --batch.  It's not the right
direction: breaks too many things (e.g. smartcard support) and might
even add unnecessary passphrase prompts, particularly for non-symmetric
key usage.



  parent reply	other threads:[~2013-10-04  0:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-29  9:22 bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt Ted Zlatanov
2013-09-29 15:07 ` Thierry Volpiatto
2013-09-29 17:48   ` Ted Zlatanov
2013-09-29 15:24 ` Daiki Ueno
2013-09-29 17:57   ` Ted Zlatanov
2013-10-02  7:23     ` Daiki Ueno
2013-10-02 10:34       ` Ted Zlatanov
2013-10-02 12:48         ` Daiki Ueno
2013-10-02 13:27           ` Andrey Kotlarski
2013-10-02 13:38           ` Ted Zlatanov
2013-10-03  1:52             ` Daiki Ueno
2013-10-03 13:59               ` Ted Zlatanov
2013-10-03 14:59                 ` Stefan Monnier
2013-10-04 21:05                   ` Ted Zlatanov
2013-10-05 16:21                     ` Stefan Monnier
2013-10-07 18:15                       ` Ted Zlatanov
2013-10-07 22:46                         ` Stefan Monnier
2013-10-04  0:12                 ` Daiki Ueno [this message]
2013-10-04 16:11                   ` Ted Zlatanov
2013-09-30 18:53 ` Stefan Monnier
2013-09-30 19:24   ` Ted Zlatanov
2013-09-30 22:49     ` Stefan Monnier
2013-09-30 23:34       ` Ted Zlatanov
2013-10-01  0:40         ` Stefan Monnier
2013-10-01  1:13           ` Ted Zlatanov
2013-10-01  2:23         ` Stephen J. Turnbull

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=874n8xrj0t.fsf-ueno@gnu.org \
    --to=ueno@gnu.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).