Page MenuHome GnuPG

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.

Event Timeline

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?

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.

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

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

What about at least accepting env variables OR tilde expansions? That will make it easier to integrate with dotfiles that intentionally use a home-dir based executable without having to pass the full path, so it could work cross platforms.

i.e. I wouldn't need to swap between /home/myuser/bin/pinentry and /Users/myuser/bin/pinentry if a simple ~/bin/pinentry could work.

I'd also be interested in expanding tilde expressions for dotfiles portability, since I don't use the same username in all my machines