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