Control: affects 853935 + src:gnupg2 Hi folks--
On Thu 2017-02-02 05:37:30 -0500, Axel Beckert wrote:
> It seems that rephrase is incompatible or at least not yet ported to
> GnuPG 2.x.
>
> Trying to use it on Sid or Stretch causes one pinentry window popup per
> guessed try (i.e. potentially thousands). And since pinentry usually
> grabs the keyboard, I can't press Ctrl-C or similar on rephrase itself.
>
> Pressing Cancel or the Escape key in the pinentry window does not end
> the rephrase session either but just makes the next pinentry window pop
> up. This makes the X session unusable until either:
>
> * No more tries are left
> * gpg is killed from outside the X session (e.g. text console or via SSH)
>
> I then tried to see if it at least works in general and tried it with
> only very few variants (2 variants, hence 4 tries), but even if the
> correct passphrase was under those very few tries (tried with 2 and 4
> tries), rephrase fails to recognize the correct passphrase and always
> ends with the following message:
>
> Passphrase doesn't match pattern (or no such key/file/device)
>
> I think to solve this issue for Debian Stretch in the short term,
> rephrase needs to
>
> 1) depend on "gnupg1" instead of "gnupg", and
> 2) replace all calls to "gpg" with "gpg1".
>
> The following patch fixes the issue for me and also reports the correct
> passphrase if it was under the given variants.
I don't think this is a sensible change, given the purpose of rephrase.
the 2.1.x version of GnuPG (which is what will offer /usr/bin/gpg in
debian stretch) stores its secret key material in a different way
(~/.gnupg/private-keys-v1.d) than gpg1 does (~/.gnupg/secring.gpg). If
you want rephrase to recover a partially-known passphrase against gpg
2.1.x, having one that "works" against gpg1 isn't going to be useful at
all.
A better short-term fix would be to add "--pinentry-mode", "loopback" to
the arguments passed to the gpg invocations in rephrase.c.
A slightly more robust fix would be to only add those extra arguments
conditionally, if the version of gpg is known to be >= 2.1 (for debian,
we could ignore this and just set a versioned dependency on the gnupg
package).
An even better fix, if the secret is stored in the 2.1.x way, would be
to connect to gpg-agent directly and never need to launch a new process,
but that would be a pretty large overhaul.
--dkg
signature.asc
Description: PGP signature
