[pkg-gnupg-maint] Bug#839991: gnupg-agent: 'allow-emacs-pinentry' setting in agent conf makes gpg2 respond no secret key

Daniel Kahn Gillmor dkg at fifthhorseman.net
Fri Oct 7 22:52:46 CEST 2016


Control: found 839991 2.1.15-4
Control: affects 839991 src:pinentry

Hi Kevin!

(i'm cc'ing the upstream mailing list about this, hope that's OK)

On Fri 2016-10-07 03:46:06 -0400, Kevin Brubeck Unhammer wrote:
> Package: gnupg-agent
> Version: 2.1.11-6ubuntu2

hm, this isn't a debian version number.  I've just tried to replicate in
debian, though, and found the same behavior in 2.1.15-4.

> and then I tried "gpg --decrypt ~/.authinfo.gpg" from a regular
> terminal (not inside Emacs). This gave me the confusing message "no
> secret key", where before it had worked just fine (with a gtk2
> pinentry dialog asking for my password).
>
> Removing the "allow-emacs-pinentry" and doing "gpgconf --reload
> gpg-agent" makes regular "gpg --decrypt ~/.authinfo.gpg" work again.

here's what i'm seeing in gpg-agent's log when i have "debug-pinentry"
turned on:

Oct 07 16:39:10 alice gpg-agent[20025]: starting a new PIN Entry
Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 <- OK Pleased to meet you, process 20025
Oct 07 16:39:10 alice gpg-agent[20025]: DBG: connection to PIN entry established
Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 -> OPTION grab
Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 <- OK
Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 -> OPTION ttytype=rxvt
Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 <- OK
Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 -> OPTION allow-emacs-prompt
Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 <- ERR 83886140 Not supported <Pinentry>
Oct 07 16:39:10 alice gpg-agent[20025]: DBG: error calling pinentry: Not supported <Pinentry>
Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 -> BYE
Oct 07 16:39:10 alice gpg-agent[20025]: failed to unprotect the secret key: Not supported
Oct 07 16:39:10 alice gpg-agent[20025]: failed to read the secret key
Oct 07 16:39:10 alice gpg-agent[20025]: command 'PKSIGN' failed: Not supported <Pinentry>
Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_8 -> ERR 83886140 Not supported <Pinentry>
Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_8 <- [eof]
Oct 07 16:39:10 alice gpg-agent[20025]: handler 0x7fc8e9a95700 for fd 8 terminated

> If Debian needs to remove Emacs pinentry support from gnupg, it should
> probably still have a better error message.

I think the bug here is that gpg-agent shouldn't choke if it asks for
allow-emacs-prompt but it's not available.

The relevant code is in agent/call-pinentry.c:

------------
  if (opt.allow_external_cache)
    {
      /* Indicate to the pinentry that it may read from an external cache.

         It is essential that the pinentry respect this.  If the
         cached password is not up to date and retry == 1, then, using
         a version of GPG Agent that doesn't support this, won't issue
         another pin request and the user won't get a chance to
         correct the password.  */
      rc = assuan_transact (entry_ctx, "OPTION allow-external-password-cache",
                            NULL, NULL, NULL, NULL, NULL, NULL);
      if (rc && gpg_err_code (rc) != GPG_ERR_UNKNOWN_OPTION)
        return unlock_pinentry (rc);
    }

  if (opt.allow_emacs_pinentry)
    {
      /* Indicate to the pinentry that it may read passphrase through
	 Emacs minibuffer, if possible.  */
      rc = assuan_transact (entry_ctx, "OPTION allow-emacs-prompt",
                            NULL, NULL, NULL, NULL, NULL, NULL);
      if (rc && gpg_err_code (rc) != GPG_ERR_UNKNOWN_OPTION)
        return unlock_pinentry (rc);
    }
------------

I don't think i understand the logic of the comment in the first
stanza.  should "a version of GPG Agent that doesn't support this" be "a
version of pinentry that doesn't support this" ?  Even so, i don't see
why the pinentry should hard-fail here.

In any case, even if the logic of the first stanza is correct and it
should be terminating if that option isn't available, it's not clear
that the same logic applies to allow-emacs-prompt.

Some pinentries that we ship in debian *do* support an external
passphrase cache, and others do not (as a way to minimize dependencies
on systems that will never run a passphrase cache like gnome-keyring).
Does that mean that all those minimal pinentries must never work?

No debian pinentries currently support emacs mode, fwiw.  But whether
they should or not is probably a different bug report than this one.

     --dkg



More information about the Gnupg-devel mailing list