Bug#839991: [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, d...@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.


pgpBaeHDSh1b6.pgp
Description: PGP signature

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

[Kevin Brubeck Unhammer]

Daniel Kahn Gillmor  čálii:

[...]

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

That resolves it for me :) I'd love to have Emacs prompts as well of
course, but as someone mentioned, that's a different issue.

Thanks a bunch!


-Kevin



signature.asc
Description: PGP signature

Bug#839991: [pkg-gnupg-maint] 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


signature.asc
Description: PGP signature

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

[Justus Winter]

Daiki Ueno  writes:

> Werner Koch  writes:
>
>> 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.
>
> That makes sense.  How about this trivial patch?

Merged, thanks!

Justus


signature.asc
Description: PGP signature

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

[Werner Koch]

On Mon, 10 Oct 2016 10:39, u...@gnu.org said:

> That makes sense.  How about this trivial patch?

Fine.  Justus, can you please apply it?


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpUGWaP6ONgY.pgp
Description: PGP signature

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

[Daiki Ueno]

Werner Koch  writes:

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

That makes sense.  How about this trivial patch?

Regards,
-- 
Daiki ueno
>From 7546cf8afd4c28c8b6615f28a4f23060b7853314 Mon Sep 17 00:00:00 2001
From: Daiki Ueno 
Date: Mon, 10 Oct 2016 10:33:36 +0200
Subject: [PATCH] core: Don't report error on setting option

Previously "OPTION allow-emacs-pinentry" returned an error if the Emacs
pinentry is not compiled in.  Since it is merely an option, it would
make more sense to just return OK.

Suggested by: Werner Koch 
Signed-off-by: Daiki Ueno 
---
 pinentry/pinentry.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/pinentry/pinentry.c b/pinentry/pinentry.c
index e5cb806..3131b1e 100644
--- a/pinentry/pinentry.c
+++ b/pinentry/pinentry.c
@@ -910,8 +910,6 @@ option_handler (assuan_context_t ctx, const char *key, const char *value)
 {
 #ifdef INSIDE_EMACS
   pinentry_enable_emacs_cmd_handler ();
-#else
-  return gpg_error (GPG_ERR_NOT_SUPPORTED);
 #endif
 }
   else if (!strcmp (key, "invisible-char"))
-- 
2.7.4

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

[Werner Koch]

Hi!

[CCing Ueno-san as Emacs Pinentry author]

On Fri,  7 Oct 2016 22:52, d...@fifthhorseman.net said:

> Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_9 <- OK Pleased to meet 
> you, process 20025

Note to self: We should really print the type and version of the
Pinentry here.

> 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 

Okay, so pinentry knows about this option but opts to tell the caller
that it does not support it.

In gpg-agent we 

>   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);

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.

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.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgp_4qGNWtyH2.pgp
Description: PGP signature

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

[Daniel Kahn Gillmor]

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 
Oct 07 16:39:10 alice gpg-agent[20025]: DBG: error calling pinentry: Not 
supported 
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 

Oct 07 16:39:10 alice gpg-agent[20025]: DBG: chan_8 -> ERR 83886140 Not 
supported 
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