generic and flexible bindings for gpg without race conditions

[Daniel Kahn Gillmor]

Hi all--

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
> invocations).
>
> 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
do better?

What is the right approach here?

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 962 bytes
Desc: not available
URL: </pipermail/attachments/20161123/7b5e758b/attachment.sig>