Bug#853935: rephrase: No more works with gpg2 and causes one pinentry popup per guess

Axel Beckert abe at debian.org
Fri Feb 3 17:54:38 UTC 2017

Control: tags -1 - patch

Hi Daniel,

thanks for your insight on that topic.

Daniel Kahn Gillmor wrote:
> > 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.

I see that one of my assumptions was wrong:

I do seem to be able to do --export-secret-subkeys without a
passphrase in some cases and can import those again with gpg1, but I
can't do that with --export-secret-keys. So my idea to export them
with gpg2 and import them with gpg1 and then use rephrase won't work.

> A better short-term fix would be to add "--pinentry-mode", "loopback" to
> the arguments passed to the gpg invocations in rephrase.c.

I'll try to come up with a patch for that.

		Regards, Axel
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

More information about the forensics-devel mailing list