generic and flexible bindings for gpg without race conditions
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Wed Nov 23 20:45:19 CET 2016
On Tue 2016-10-11 20:49:32 -0400, Daniel Kahn Gillmor wrote:
> 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 :/
I haven't heard any responses to this question. Are there any
suggestions? I note that gpgme invokes a subprocess to get this
information (_gpgme_get_program_version in src/version.c), which seems
not only expensive, but racy: it's certainly possible for gpg to be
upgraded between the initial invocation and subsequent accesses. Can we
What is the right approach here?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 962 bytes
Desc: not available
More information about the Gnupg-devel