Your message dated Sat, 5 Apr 2025 13:53:48 +0200 with message-id <[email protected]> and subject line Re: Bug#735241: gnupg2: gpg2 does not work with --batch --passphrase string has caused the Debian Bug report #735241, regarding gnupg2: gpg2 does not work with --batch --passphrase string to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 735241: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735241 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: gnupg2 Version: 2.0.22-3 Severity: normal Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? Writing a script to sign arbitrary selections, I use zenity to retrieve a string from the user to be passed to gpg2 as passphrase. This is because the script needs to be launched from a hotkey in X and gpg's passphrase dialog does not work in this context. * What exactly did you do (or not do) that was effective (or ineffective)? In testing the script I ran the following from xfce4-terminal: gpg -s --batch --no-tty --passphrase [my gpg passphrase] * What was the outcome of this action? the normal passphrase prompt window popped up. * What outcome did you expect instead? I expected that gpg should proceed as normal except omitting the passphrase prompt as one had been provided by --passphrase per the manual. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnupg2 depends on: ii dpkg 1.17.5 ii gnupg-agent 2.0.22-3 ii install-info 5.2.0.dfsg.1-2 ii libassuan0 2.1.1-1 ii libbz2-1.0 1.0.6-5 ii libc6 2.17-97 ii libcurl3-gnutls 7.34.0-1 ii libgcrypt11 1.5.3-3 ii libgpg-error0 1.12-0.2 ii libksba8 1.3.0-3 ii libreadline6 6.2+dfsg-0.1 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages gnupg2 recommends: ii libldap-2.4-2 2.4.31-1+nmu2+b1 Versions of packages gnupg2 suggests: ii gnupg-doc 2003.04.06+dak1-1 pn xloadimage <none> -- no debconf information
--- End Message ---
--- Begin Message ---Version: 2.2.44-1 On 2014-01-14 Andrew Kane <[email protected]> wrote: > On Mon, Jan 13, 2014 at 2:05 PM, Andrew Kane <[email protected]> > wrote: >> Package: gnupg2 >> Version: 2.0.22-3 >> Severity: normal >> Dear Maintainer, >> *** Please consider answering these questions, where appropriate *** >> * What led up to the situation? >> Writing a script to sign arbitrary selections, I use zenity to retrieve a >> string from the user to be passed to gpg2 as passphrase. >> This is because the script needs to be launched from a hotkey in X and gpg's >> passphrase dialog does not work in this context. >> * What exactly did you do (or not do) that was effective (or >> ineffective)? >> In testing the script I ran the following from xfce4-terminal: >> gpg -s --batch --no-tty --passphrase [my gpg passphrase] >> * What was the outcome of this action? >> the normal passphrase prompt window popped up. >> * What outcome did you expect instead? >> I expected that gpg should proceed as normal except omitting the passphrase >> prompt as one had been provided by --passphrase per the manual. > It turns out that this works if the --no-use-agent switch is used. > This wasn't clear to me from the documentation. Nowadays the manpage says: --passphrase string Use string as the passphrase. This can only be used if only one passphrase is supplied. Obviously, this is of very questionable security on a multi-user system. Don't use this option if you can avoid it. Note that since Version 2.0 this passphrase is only used if the option --batch has also been given. Since Version 2.1 the --pinentry-mode also needs to be set to loopback.
--- End Message ---
