'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


More information about the Gnupg-users mailing list