[PATCH] gpg: respect user-defined GPG_OPTS precedence
Jaume Casado Ruiz
minterior at gmail.com
Thu Apr 2 16:18:53 UTC 2026
Hello everyone,
I recently encountered an issue while using 'pass' in a remote session
(SSH + screen). When trying to access a password, GPG would fail with
the following error:
gpg: can't get input
This happens because the environment requires an interactive TTY-based
pinentry, but 'pass' hardcodes the --batch flag. I found some
discussion on the Arch Linux forums [1] where users suggested
manually removing the --batch flag from the 'pass' source code to
fix this.
Instead of removing a default that might be useful for automation, I
looked into GPG's documentation and found the --no-batch flag.
However, providing --no-batch via $PASSWORD_STORE_GPG_OPTS does
not currently work because 'pass' appends its own --batch flag
*after* the user-defined options. Since GPG honors the last
occurrence of a flag, the hardcoded --batch always wins.
This patch reorders the arguments (or ensures GPG_OPTS precedence)
so that users can explicitly override the default behavior. With this
change, running:
PASSWORD_STORE_GPG_OPTS="--no-batch" pass <name>
works perfectly in SSH/screen/tmux sessions by allowing the
interactive pinentry-tty to take over.
[1] https://bbs.archlinux.org/viewtopic.php?id=208059
-----------------------------------------------------------------------------------------------------
From 35142707165bb67f4514592be411b47d34f02f5e Mon Sep 17 00:00:00 2001
From: Jaume Casado Ruiz <minterior at gmail.com>
Date: Thu, 2 Apr 2026 05:24:45 +0200
Subject: [PATCH] gpg: respect user-defined GPG_OPTS precedence
The current implementation appends internal GPG flags after the
$PASSWORD_STORE_GPG_OPTS variable. Since GPG typically honors the
last occurrence of a flag on the command line, this prevents users
from overriding default behaviors.
A specific case is the hardcoded --batch flag. In remote sessions
(e.g., SSH, screen, or tmux) that require an interactive TTY-based
pinentry, users cannot re-enable interactivity. Even if --no-batch
is provided via PASSWORD_STORE_GPG_OPTS, the trailing --batch forces
a non-interactive mode, resulting in "gpg: can't get input" errors.
By ensuring PASSWORD_STORE_GPG_OPTS takes precedence, users gain the
necessary flexibility to handle interactive prompts in restricted
environments without breaking existing automation.
---
src/password-store.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/password-store.sh b/src/password-store.sh
index 22e818f..456cdc9 100755
--- a/src/password-store.sh
+++ b/src/password-store.sh
@@ -6,11 +6,12 @@
umask "${PASSWORD_STORE_UMASK:-077}"
set -o pipefail
-GPG_OPTS=( $PASSWORD_STORE_GPG_OPTS "--quiet" "--yes"
"--compress-algo=none" "--no-encrypt-to" )
+GPG_OPTS=( "--quiet" "--yes" "--compress-algo=none" "--no-encrypt-to" )
GPG="gpg"
export GPG_TTY="${GPG_TTY:-$(tty 2>/dev/null)}"
command -v gpg2 &>/dev/null && GPG="gpg2"
[[ -n $GPG_AGENT_INFO || $GPG == "gpg2" ]] && GPG_OPTS+=( "--batch"
"--use-agent" )
+GPG_OPTS+=( $PASSWORD_STORE_GPG_OPTS )
PREFIX="${PASSWORD_STORE_DIR:-$HOME/.password-store}"
EXTENSIONS="${PASSWORD_STORE_EXTENSIONS_DIR:-$PREFIX/.extensions}"
--
2.53.0
--
Jaume Casado Ruiz
GPG Key ID: 0xD9AB39238DF66919
Free software my friend ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20260402/d71721b7/attachment.sig>
More information about the Password-Store
mailing list