Bug#853935: [pkg-gnupg-maint] Bug#853935: rephrase: No more works with gpg2 and causes one pinentry popup per guess

[Daniel Kahn Gillmor]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/forensics-devel/attachments/20170202/5915d2d6/attachment.sig>