'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key)
Carola Grunwald
caro at nymph.paranoici.org
Wed May 11 01:20:54 CEST 2016
On Tue, 10 May 2016 11:35:33 +0200, Werner Koch <wk at gnupg.org> wrote:
>On Tue, 10 May 2016 09:47, caro at nymph.paranoici.org said:
>
>> Meanwhile I'm sure it's a bug similar to
>> https://bugs.gnupg.org/gnupg/issue2324.
>
>Not really.
>
>> GnuPG 2.1 isn't ready for embedded usage yet.
>> It's still experimental, so we have to wait.
>
>No, it is not experimental, but you have a rare use case by doing
>unattended deletion of secret keys. FWIW, You would have run into a
>very similar problem with gpgsm for more than a decade.
When an application creates a key it also has to get it deleted.
With the 1.4 branch I interacted with the GnuPG process completely
unattended through standard-I/O pipes, which now are replaced by the
pinentry mechanism, where redirections fail.
>
>I just pushed the attached fix. (consider
> s/--disallow-loopback-passpharse/--no-allow-loopback-pinentry/
>for the commit message)
>
>You should be able to apply this to 2.1.12. GPGME probably needs an
>update too.
Many thanks. But I'm on Windows, dependent on binaries. Without
nightly builds I have to wait for the next release, or try to
crosscompile it in my Debian VM, which I doubt to manage.
Kind regards
Caro
More information about the Gnupg-users
mailing list