Page MenuHome GnuPG

gpg 2.2.9 breaks incompatibly and creates options mess
Closed, ResolvedPublic

Description

Dear all,

manpage claims: ".. --passphrase string Use string as the passphrase. .."

Gpg straightforwardly worked like this in previous versions.

Probably since gpg2, the supplied passphrase is ignored and an
annoying "pinentry" popup pops up.

I can remedy if I provide "--batch" and (!) "--pinentry-mode loopback"
on top.

While this is sort of documented to those who do not get lost in the
docs, see quotation below, how many options does gpg want to read in
order to respect "--passphrase"?

Will you fix?

Many thanks!

Mirko

Microsoft Windows [Version 10.0.17134.165]
(c) 2018 Microsoft Corporation. Alle Rechte vorbehalten.

c:\Users\Mirko>gpg --version
gpg --version
gpg (GnuPG) 2.2.9-unknown
libgcrypt 1.8.3
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

..

'--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'.

..

Details

Version
2.2.9

Event Timeline

aheinecke claimed this task.
aheinecke added projects: Duplicate, gnupg, gpg4win.
aheinecke added a subscriber: aheinecke.

Hi Mirko,

I feel your pain. The idea behind this was to underline that providing the passphrase on the command line is often a bad idea and insecure. You should not need --batch. --pinentry-mode loopback should be enough.

Personally I disagree with such hurdles to educate users and would like to see gnupg automatically use pinentry-mode loopback if a --passphrase option is provided. But this is not my decision and other developers have different opinions. I've opened an issue some time ago to at least give a clear error. T4020

So I tend to close this issue as a duplicate of T4020 the problem is the same. The need for --pinentry-mode loopback is not user friendly and hard to discover.

Best Regards,
Andre

Dear Andre , all , T4020 does not even well-define the symptom and I
do not agree T4020 is a duplicate of T4079 . I'd close T4020 in favor
of T4079 . Many thanks . Mirko