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

[Werner Koch]

On Tue, 11 Oct 2016 22:36, dkg at fifthhorseman.net said:

> 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

That depends on whether the pinentry considers missing support for this
option important enough to fail.

> 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?

New pinentries should use the framework of the standard pinentry.
Recent pinentries support the option and will always return OK in that
case.  The whole problem here was a bug in the emacs pinentry.

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

I think so.  IIRC, we had to implement it this way to make it work in
All Cases (tm).  Neal might know more about it.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20161019/44c7a8a4/attachment.sig>