generic and flexible bindings for gpg without race conditions

Daniel Kahn Gillmor dkg at
Wed Oct 12 02:49:32 CEST 2016

hi all--

I'm trying to clean up the GnuPG::Interface perl bindings and i want to
make it work independently of whether the user has the classic, stable,
or modern suite installed.

GnuPG::Interface has traditionally offered a mode for users to provide
the password programmatically, and then passed the password to the gpg
process.  I will probably urge the GnuPG::Interface maintainer to
discourage this use pattern in favor of delegating access decisions to
the agent or a custom pinentry, but they will likely want to support
this mode for some time into the future.

With modern GnuPG, using this "send the password explicitly" mode
requires --pinentry-mode=loopback, but neither classic nor stable
supports this argument.

As a result, i don't know how to decide what to send: either i supply
--pinentry-mode=loopback (and fail on classic and stable because of
"Invalid option") or i don't supply it (and the passphrase doesn't get
seen by modern at all).

I could test the version of gpg, at the not-insignificant expense of an
additional subprocess ("gpg --version"), and a possible race condition
(the subsequent call to gpg could hit a different installed gpg process
than the one tested with --version if there was an upgrade in between

One way to resolve this would be to add --pinentry-mode=loopback as a
dummy no-op parameter to classic and modern.  This doesn't help for old
installations, of course, but if someone can upgrade within a given
series, it would at least let the bindings work.

Are there other solutions to this conundrum?  The upgrade path here is
tricky and kind of fraught :/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20161011/1d67df19/attachment.sig>

More information about the Gnupg-devel mailing list