[pkg-gnupg-maint] Bug#842015: Bug#842015: Bug#842015: Similar issue, no emacs

[Daniel Kahn Gillmor]

On Thu 2016-11-03 03:33:47 -0400, Werner Koch wrote:
> On Thu,  3 Nov 2016 04:52, dkg at fifthhorseman.net said:
>
>> a bit of background:
>
> Thanks for that good summary.
>
>>  * pinentry-gnome3: d-bus, fallback to terminal if d-bus connectivity
>>    fails (this is actually somehow mixed at the moment; it's not clear
>>    whether pinentry should fall back to the terminal only if
>>    $DBUS_SESSION_BUS_ADDRESS is unset, or whether it should *also*
>>    fallback to the terminal if the prompting agent itself is
>>    unavailable; i lean toward the latter, but Werner has declined a
>>    patch that makes that happen)
>
> I rejected the patch due to the way it worked.  A patch working similar
> to the tty fallback would be okay.  Something like this:
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
> index d6d7d16..e79e852 100644
> --- a/gnome3/pinentry-gnome3.c
> +++ b/gnome3/pinentry-gnome3.c
> @@ -270,6 +270,11 @@ main (int argc, char *argv[])
>                 " falling back to curses\n");
>        pinentry_cmd_handler = curses_cmd_handler;
>      }
> +  else if (is_gcr_installed ())
> +    {
> +      fprintf (stderr, "No GCR found, falling back to curses\n");
> +      pinentry_cmd_handler = curses_cmd_handler;
> +    }
>  #endif
> --8<---------------cut here---------------end--------------->8---
>
> I do not know how to test for GCR availability, though.

i do not either, but i will work on a patch that provides something
approximating this approach today.

fwiw, the difference between these approaches is that the
originally-proposed patch tests for gcr avaiability at the time of
GETPIN, and your proposed approach tests for gcr availability at the
time of the invocation of pinentry.

I'm not sure why you prefer it that way.  If pinentry is used as a
long-running co-process (or even a moderately-long-running process),
it's entirely possible that a given d-bus session has the ability to do
a gcr prompt at one point but not at another.  It would seem to me that
the most effective time to test would be when the actual prompt is
requested.  I'm curious to understand the argument for the other
approach.

> I would like to implement a method to make it easier to show the problem
> to the user.  For me it is easy to debug becuase I know how to use
> watchgnupg but users only see the output of gpg (if at all) and not the
> gpg-agent logs. 
>
> This could be implemented by extending the PINENTRY_LAUNCHED
> notification we already use between gpg and gpg-agent to print a
> diagnostic and a status line with the type of the pinentry in use and a
> couple of flags:
>
>   [GNUPG:] PINENTRY_LAUNCHED <pid>  <type> <version> <flags>
>
> <type> would be gtk/gnome/qt and flags can be used to indicate the
> chosen fallback.  Requires some additions to the pinentry, though.
>
> Would this be helpful?

It would be great to get better error messages in the hands of users.
Anything in that direction is welcome.

         --dkg