Page MenuHome GnuPG

Using '--passphrase-fd 0' forces pinentry (STDIN ignored)
Closed, InvalidPublic

Description

In 2.0.26 this works as expected - the passphrase is accepted from STDIN during
scripts:

echo XXXX | /usr/bin/gpg --sign --default-key 15DE5E40 --passphrase-fd 0 --batch
-r 15DE5E40 -o /tmp/duply.5459.1416887390_ENC -e /usr/bin/duply

According to the 2.1.x docs, 'echo FOO | gpg --passphrase-fd 0' is still
supported, however it appears to ignore STDIN and always forces pinentry from
gpg-agent which I think is a bug. (note: I have no special
gpg.conf/gpg-agent.conf settings - vanilla setup)

I also created a full package (Arch) for 2.1.1-beta44 from git (make distcheck)
to test; I validated this bug by grabbing pinentry.sh from tests/openpgp/ and
making that my pinentry program in ~/.gnupg/gpg-agent.conf - by editing
pinentry.sh and hard-encoding the passphrase it "works" (in that this suffices
for pinentry), however everything from STDIN is still ignored. I can play with
the passphrases to ensure that it's broken; however once it's added correctly to
gpg-agent the process works as expected.

Compile options:

./configure --prefix=/usr --sysconfdir=/etc --sbindir=/usr/bin
--libexecdir=/usr/lib/gnupg --enable-maintainer-mode --enable-symcryptrun
--enable-gpgtar

The expectation is that the 'echo FOO | gpg --passphrase-fd 0' works without
gpg-agent and/or pinentry popping up (for use in scripts) as it does in 2.0.26.
I noticed that in 2.0.26 the gpg-agent was *not* launched and left running in
the background, however on 2.1.0/2.1.1-beta44 it's launched/stays running. This
may just be changed behaviour though and expected.

Details

Version
2.1.1-beta44 (git)

Event Timeline

A few Arch users are reporting the same regression/breakage, thread here:

https://bbs.archlinux.org/viewtopic.php?pid=1479136

Like gpgsm has done from its very beginnong, gpg now also does not pknow
anything about the secret keys. This is all delagted to gpg-agent. This means
that telling gpg a passphrase is useless.

But wait. There is a workaround: gpg has the new option

   --pinentry-mode mode
          Set the pinentry mode to mode.  Allowed values for mode are:

          default
                 Use the default of the agent, which is ask.

          ask    Force the use of the Pinentry.

          cancel Emulate use of Pinentry's cancel button.

          error  Return a Pinentry error (``No Pinentry'').

          loopback

                 Redirect Pinentry queries to the caller.  Note that
                 in contrast to Pinentry the user is not prompted
                 again if he enters a bad pass- word.

Thus by using

  gpg --pinentry-mode=loopback

you can do basically the same as with 1.4. It is well tested and
slighly different than in 1.4. Uou also need to configure gpg-agent
with

  --allow-loopback-pinentry

       Allow clients to use the loopback pinentry features; see the
       option pinentry-mode for details.
werner lowered the priority of this task from High to Normal.
werner removed a project: Bug Report.

Roger that, thanks - I've tested it on a VM with my keys and things seem "like
they used to be" for scripting an automated passphrase entry. I specified them
in my ~/.gnupg/pgp.conf and ~/.gnupg/gpg-agent.conf since editing many
individual softwares is not possible at this time, it needs to be backwards
compatible.

What side affects (breaking things?) does having these options permanently
enabled in configs are there? Having the allow in gpg-agent.conf is harmless,
but what about the client side gpg.conf?

If client gpg '--passphrase-fd 0' is useless without '--pinentry-mode loopback',
why not make this an automatic added option (internally) if '--passphrase-fd 0'
is specified? Of what use with gnupg-2.1.x is '--passphrase-fd 0' without
'--pinentry-mode loopback'?

I double-checked the official docs, there's no mention of needing these new
loopback settings in the section for --passphrase-fd 0:

https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html#GPG-Esoteric-Options

"If you use 0 for n, the passphrase will be read from STDIN." (but as we know
here, it's not unless the new loopback options are added)

If you add it to gpg.conf the Pinentry won't be used and there are fir sure
cases where things won't work. In an unattended use I can't see a problem right
now.

We can't change the behaviour of --passpharse-fd; it is widely used and:

  if ( !opt.batch && opt.pinentry_mode != PINENTRY_MODE_LOOPBACK)
    { /* Not used but we have to do a dummy read, so that it won't end
         up at the begin of the message if the quite usual trick to
         prepend the passphtrase to the message is used. */

think would break or - worse - may insert the passphrase into the message.

The passphrase is still used for symmetric only encryption in batch mode.

Thanks werner -- I've filed an upstream issue to bring awareness of the change
to the software I use that was affected (duply/duplicity), I'm sure this is
going to pop up for others as 2.1 becomes more widely adopted. Maybe add
something to the release notes or docs for '--passphrase-fd 0' so folks know a
config change is needed in their apps and gpg-agent? Regardless, I appreciate
your help.

(marking as resolved)