decrypt does not work with gpg 2.1.9 without '--pinentry-mode loopback'

[dmarsic]

Decrypt (decrypt()) does not work for me unless passphrase has been previously passed to gpg2.

I'm using:

python-gnupg version 2.0.2
gpg (GnuPG) 2.1.9

My use case is relatively simple:

...     g.decrypt(f.read(), passphrase=passphrase, output=decfile)

If I trace it with strace, I see "Inappropriate ioctl for device " message.

$ strace -fqq -s512 <command>
[pid  3645] <... read resumed> "ERR 83918950 Inappropriate ioctl for device <Pinentry>\n", 1002) = 55

I was able to make it work by:

• Enabling gpg-agent to run with allow-loopback-pinentry, and

$ grep allow-loopback-pinentry ~/.gnupg/gpg-agent.conf 
allow-loopback-pinentry

• Adding --pinentry-mode loopback as an additional parameter to gnupg. I added it under GPGBase._make_args() and tested that decryption works.

Can --pinentry-mode loopback be added to gnupg?

[isislovecruft]

Can --pinentry-mode loopback be added to gnupg?

@dmarsic Yes. Thanks for reporting this! I'll add it now.

[isislovecruft]

@dmarsic This should be fixed in python-gnupg version 2.2.0. If not, please feel free to reopen!

[sakof]

I'm quite new to python-gnupg, but it seems to me that I'm having this issue with 2.2.0.

(virtualenv) [root@9e6873a92dbc gnupg]# pip freeze | grep gnupg
gnupg==2.2.0

On fedora:24 docker image from docker hub.

(virtualenv) [root@9e6873a92dbc app]# rpm -qa | grep gnupg
gnupg2-2.1.11-3.fc24.x86_64
(virtualenv) [root@9e6873a92dbc app]# cat /etc/redhat-release 
Fedora release 24 (Twenty Four)
(virtualenv) [root@9e6873a92dbc app]# rpm -qa | grep gnupg
gnupg2-2.1.11-3.fc24.x86_64
(virtualenv) [root@9e6873a92dbc app]# cat /etc/redhat-release 
Fedora release 24 (Twenty Four)

Output:

[GNUPG:] ENC_TO 47DF3239117392C2 1 0
[GNUPG:] PINENTRY_LAUNCHED 387
gpg: encrypted with 2048-bit RSA key, ID 117392C2, created 2016-12-30
      "Autogenerated Key <077ea6bacc2311e698bae8b1fcf138b2>"
gpg: public key decryption failed: Inappropriate ioctl for device
[GNUPG:] ERROR pkdecrypt_failed 83918950
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] DECRYPTION_FAILED
gpg: decryption failed: No secret key
[GNUPG:] END_DECRYPTION

[piccoloaiutante]

I'm having the same issue with 2.2.0 on OSX 10.12.2 while decrypting:

gpg: WARNING: unsafe permissions on homedir `./.gpg\\'
gpg: enabled debug flags: memstat
[GNUPG:] ENC_TO 9F1222C230B6E2F9 1 0
gpg: encrypted with RSA key, ID 30B6E2F9
[GNUPG:] NO_SECKEY 9F1222C230B6E2F9
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] DECRYPTION_FAILED
gpg: decryption failed: No secret key
[GNUPG:] END_DECRYPTION
random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
secmem usage: 224/32768 bytes in 1 blocks

[redshiftzero]

to the above commenters, I ran into similar problems and I would confirm the following (since these comments are from early 2017 you probably solved already ha, but this comment is for the sake of the person googling this error message):

1. Confirm that options=['--pinentry-mode loopback'] is used: gpg = gnupg.GPG(binary='gpg2', homedir=gpg_key_dir, options=['--pinentry-mode loopback'])
2. Confirm that permissions are correct on your gpg home directory, file contents, and sub directories: directories should have 700, other files 600.
3. Confirm that allow-loopback-pinentry has been added to gpg-agent.conf
4. Confirm no gpg-agent processes are running (i.e. ps aux | grep gpg-agent)

[pwillis-els]

Using Ubuntu 18.04.5 and gpg 2.2.4, using screen, this same issue still seems to happen, and the above fixes the problem. The question is, why is this error still happening?

[johnnyutahh]

In my tests, the "stanard" python-gnupg module has no need for options=['--pinentry-mode loopback'] on both macOS v10.15.7 and Ubuntu 20.04.4. Plus additional benefits. Details:

https://stackoverflow.com/a/72355824/605356

Also, I find the following bash_alias/command "clears" cached passwords from the gpg-agent, removing the need to kill the gpg-agent process (per below).

alias gpg_clear_cached_passphrases='gpg-connect-agent reloadagent /bye'

4. Confirm no gpg-agent processes are running (i.e. ps aux | grep gpg-agent)