Running without pinentry (related to issue #2680)

[Milan Crha]

	Hello,
I've been asked to rise a concern about pinetry availability in
Issue2680, https://bugs.gnupg.org/gnupg/issue2680

I've made a pretty long story in a downstream bug report [1], I can
copy it here, if you prefer.

In short, there's a problem when a user calls gpg/gpg2 without any
pinentry implementation being installed. The error message I get with
gnupg2 2.1.17-1.fc26 and pinentry 0.9.7-2.fc24 is "gpg: signing failed:
Inappropriate ioctl for device". I'm pretty sure that I'll forget about
it soon, thus when other users will report a similar issue it'll mean
to reinvestigate it. I mean, a better error message would be useful in
the situation when no pinentry implementation could be found.

This is when calling gpg/gpg2 from an evolution-data-server, namely its
libcamel library. While the downstream bug report [1] suggests to add a
 package dependency to the evolution itself, I do not think it'll work,
because the libcamel can be used by anything, either through its C API,
or through introspection bindings. Adding the pinentry implementation
dependency into the evolution-data-server doesn't sound right, also
because it is desktop environment independent (the same as the
Evolution), thus it's pretty hard to choose "the right implementation",
because the respective applications (including the Evolution), can run
in any desktop environment, thus picking a wrong implementation would
cause just a bad user experience. For example Fedora offers emacs,
gnome3, gtk and qt pinentry implementations.

Werner asked whether the evolution (-data-server) uses GPGME these
days. The last time I tried, which is about a year ago, it didn't fit
the needs of the libcamel, thus the answer is no. I do not recall what
exactly was missing, I'm sorry, it's too long time. I always understood
the GPGME as an interface on top of the gpg/gpg2 calls, which is a good
thing to have (thus one doesn't need to reimplement the calls and the
overhead on top of them), but it has also its limitations. The main
difference with libcamel might be that the libcamel has its own
routines on top of it done already.

Anyway, the main question is what to do when there is no pinentry
implementation installed. Having a better error message is a good
starting point, where Werner wrote in the Issue2680 that the newer
pinentry will make it better (note I had installed the proper gnupg2,
but not the pinentry). The libcamel can do password prompts on its own
too, thus a GET_HIDDEN or similar could be requested by the gpg2 when
no pinentry implementation was found. The side effect of it would be
that the pinentry will not be tight to the desktop, but it will be
tight to the window which requested it, which is a good thing to do,
from my point of view. Werner mentioned "--pinentry-mode=loopback", but
I do not know how much backward compatible it is (the libcamel has no
version limitation on the gpg itself). Having it done by default,
without a need to specify the parameter, might be better, from my point
of view. Another option is to deal with this on the packaging level,
but it is hard to pick the right pinentry implementation and apart of
many other things, it requires a coordination between distributions.

Maybe I do this overcomplicated. I'm sorry if I do. It's just that I
see many "easy to break" things in any implementation which would be
done on the application side (a user of gpg/gpg2).
	Bye,
	Milan

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1362477#c37
    and the next comment.