gpg prompts for passphrase after upgrade to SLES 15 which includes gpg2 package 2.2.5

This document (000020595) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 15

Situation

A scripted gpg command to decrypt a file was in use on SLES 11 or SLES 12, which uses gpg2 package version 2.0.x-x. The command includes a passphrase, so it should not need to prompt for one. This is important because this script will run unattended. For example:

gpg --yes --batch --passphrase "xxxxx" --output unencrypt.txt --decrypt source.txt.asc

However, after upgrade to SLES 15 which includes gpg2 package version 2.2.5-x, the above command still prompts for a passphrase (if one is not already held in cache).

Resolution

Remove the "--batch" option and replace it with "--pinentry-mode loopback". For example:

gpg --yes --pinentry-mode loopback --passphrase "xxxxx" --output unencrypt.txt --decrypt source.txt.asc

Cause

The default behavior of gpg has changed as of gpg2 v2.1. In the man page for gpg, within the explanation of the
--passphrase option, the following statement is now present:

"Since Version 2.1 the --pinentry-mode also needs to be set to loopback."

Additional Information

While testing various syntax for whether or not gpg prompts for a passphrase, it can be frustrating that the same syntax will sometimes prompt for passphrase but sometimes it will not. This is usually because a correctly accepted passphrase will be cached for a period of time (10 minutes by default), making it unnecessary to request it on subsequent executions. Therefore, while testing for correct command syntax, it can be useful to turn off the cache.

One confirmed way to do this:

In the home directory of the user who will be executing gpg, edit (or create) the file:
~/.gnupg/gpg-agent.conf

Within that file, set the option: default-cache-ttl 0

Save that. Then find the gpg-agent for that user with:
ps aux | grep gpg-agent | grep <username>

For example:

sles15sp2:~ # ps aux | grep gpg-agent | grep root
root 8748 0.0 0.1 166368 1292 ? Ss 17:38 0:00 gpg-agent --homedir /root/.gnupg --use-standard-socket --daemon
root 8819 100 0.0 7424 860 pts/1 S+ 17:49 0:00 grep --color=auto gpg-agent

In the above example, the PID of the agent is 8748.

Kill the process with it's PID. In this example, the command would be:
kill 8748

Then make new attempts at using gpg from the command line. This should automatically cause gpg-agent to launch again, and will now use the new cache time (0 = no cache). With the cache off, testing gpg and interpreting the results should be more reliable.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.