gpg-agent should guess pinentry's full path (using $PATH) if `pinentry-program` does not supply a full path
Open, NormalPublic


gpg-agent's pinentry-program configuration option currently expects a full path.

In my experience of helping people debug GnuPG, it is very common to see people place an unadorned program name in that configuration option, and then get confused about why nothing is working.

for example:

pinentry-program pinentry-qt

simply doesn't work, even when pinentry-qt is installed and is on the $PATH.

And when it doesn't work, the error message is particularly opaque because most people don't know how to chase down the problem. gpg-agent's own error message is:

ERR 67108949 No pinentry <GPG Agent>

Which is implausible for users who say "but of course it exists, i can run pinentry-qt directly from the command line".

Apparently pinentry is launched by assuan_pipe_connect, with the argument showing up in the NAME variable to that function.

So either this should be fixed by assuan being willing to search $PATH if NAME is not absolute, or gpg-agent at least should search path and send an updated NAME.

dkg created this task.Jun 27 2019, 5:35 PM
werner added a subscriber: werner.

GnuPG invokes its components always with their absolute file name. We want to mitigate attacks where malware creates a pinentry wrapper somewhere in an improper set PATH.

What about adding a dedicated note on how to properly configure pinentry?

dkg added a comment.Jul 1 2019, 6:24 PM

So this is a defense against an adversary capable of creating a pinentry-wrapper somewhere in $PATH, but not capable of modifying gpg-agent.conf? It sounds to me like this is a defense against a very unusually-constrained attacker, at the expense of regular, common bug reports and user confusion.

I don't understand this tradeoff.

werner added a comment.Jul 1 2019, 9:33 PM

As I said we do this with all GnuPG components. Pinentry is a bit of exception because it is an external package.
I have also had bug reports which later turned out that a wrong pinentry was used; I prefer to know eactly which pinentry is used. Regarding your concrete problem I suggested to add a note with the full name of the pinentry or to change the error message to something better understandable.

werner triaged this task as Normal priority.Jul 1 2019, 9:34 PM
werner edited projects, added gnupg (gpg23); removed libassuan.Oct 23 2020, 6:51 PM

What can be done is to use gpgconf --list-dirs bindir as a fallback for pinentry.