emacs-devel
[Top][All Lists]
Advanced

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

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt


From: Daiki Ueno
Subject: Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt
Date: Fri, 04 Oct 2013 09:12:34 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Ted Zlatanov <address@hidden> writes:

> On Thu, 03 Oct 2013 10:52:46 +0900 Daiki Ueno <address@hidden> wrote: 
>
> DU> Ted Zlatanov <address@hidden> 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.



reply via email to

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