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

[Daniel Kahn Gillmor]

Control: reassign 839991 pinentry
Control: affects 839991 + gpg-agent
Control: found 839991 0.9.7-5
Control: fixed 839991 0.9.7-6

On Sat 2016-10-08 04:56:52 -0400, Werner Koch wrote:

> bail out on this error because the Pinentry told us that it knows about
> the option.  So it was a Pinentry choice to return that error.
>
>> No debian pinentries currently support emacs mode, fwiw.  But whether
>> they should or not is probably a different bug report than this one.
>
> The interesting part is in Pinentry:
>
>   else if (!strcmp (key, "allow-emacs-prompt") && !*value)
>     {
> #ifdef INSIDE_EMACS
>       pinentry_enable_emacs_cmd_handler ();
> #else
>       return gpg_error (GPG_ERR_NOT_SUPPORTED);
> #endif
>     }
>
> Thus pinentry always tells us that it is not supported unless it is a
> Pinentry which was build with Emacs support.

So a pinentry implementation is expected to say something other than
"GPG_ERR_UNKNOWN_OPTION" when it sees an option it recognizes, but knows
it will have no way of implementing.  is that right?  That seems to be
the logic for allow-external-password-cache, fwiw.

Is this sort of expectation documented somewhere?  Would an implementer
of a new pinentry (or someone trying to use pinentry directly) be
expected to know this?

> Alrthough we could handle this in gpg-agent, I consider it better to fix
> this in Pinentry.  The name "allow-emacs-prompt" means to me that Emacs
> support is optional and thus Pinentry should just return OK.  A new
> Pinentry version is anyway due.

I've applied Daiki Ueno's proposed patch to debian unstable in pinentry
0.9.7-6.  hopefully it will resolve the issue here.  Kevin, can you
report back whether it resolves things for you?  (there will still be no
prompts in emacs, but at least access to the pinentry shouldn't
automatically abort).  I'm closing the issue now because i believe it's
resolved in 0.9.7-6, but feel free to reopen if you think it is still
wrong.

----

fwiw, i still don't really understand the logic behind gpg-agent's
strictness around allow-external-passphrase-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.  */

Consider pinentry-tty, which is compiled *without* libsecret on debian,
but can be co-installed with pinentry-gnome3 (which is compiled *with*
libsecret on debian).  Neither of these pinentry implementations will
report GPG_ERR_UNKNOWN_OPTION, but only one of them will actually
"respect" the flag in the sense of querying the secret service.  Is this
logic correct?

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20161011/1d50ee65/attachment.sig>