I can send my keyring to you but I would not like to make it public. Is a private
mail with a download link ok?

Just noticed: It is a keyring. So first question already answered.

I would be helpful if you could provide an example keyring and a list of keys
which have a secret key. As an alternative I like to know:

• Are you using the keybox or the keyring format (commonly ".kbx" or ".gpg").
• Is the version 3 key the first, inbetween, or the last key in the key storage?

original; report was for the dirmngr package. Won't fix it there.

dirmngr is now part of gnupg proper.
Original report was for dirmngr-1.1.0.

2.1.1 has been released.

understood - please note I used a very recent automake in testing this
without issue, but I only have an osx platform - others may experience
breakage.

This is due to a newer automake. This is not yet supported due to backward
incompatibilities since autmake 1.13. The plan is to switch to a newer automake
with the release of Debian's Jessie. See README.GIT on how to use an
alternative automake version. There is at least one other bug regarding this
problem, thus I will close yours.

Yes, this is the case for a very long time. I also won't call this a
bug.

There is no way to protect an update by a lock without having write
permissions to the same directory. Well, one could setup a second
file system hierarchy below /var/run and use that for the locking
file. However, this assume that all process accessing the files are
on the local machine. One of the reasons why we can't use a locking
API are remotely mounted file systems. See the comments in
common/dotlock.c .

And yes, we need lock the file even if the local process as no write
permissions to the directory - other processes may have and the
reading process may thus read garbage.

By using --lock-never you assert that there is no other processing
writing to the gpg data files. Thus using this is the Right Thing.

Pushed.

Give that the macro change is a no-brainer I will do that immediatly. Which
means this bug report can be closed.

This has already been fixed as well as a couple of other bugs in 2.1.0.

I will release 2.1.1 soon despite that there are a few other bugs left open.
Feel free to reopen this bug if it persists with that new release (or the
current GIT master).

Understood - would you like me to fix with automake 1.10, or park this
for a merge post-Jessie ?

automake 1.14 is not yet supported becuase it defaults to the new parallel tests
and automake 1.11 has no way to disable this tests (serial-tests option in 1.14).

After the release of Debian Jessie I plan to migrate to 1.14 and drop support
form earlier automakes.

oh, and this appears to be the case for 1.4.x, 2.0.x, and 2.1.x

That link to the debian bts is a little wacky, somehow roundup is attaching the
comma to the end of it. it should be: https://bugs.debian.org/771976

That is... just far too obvious for words. *facepalm*

Okay, this works nicely for my needs. Wrapper scripts can turn it into a
site-wide policy.

I can confirm it too. Thank you for this fix.

confirmed

You need to create a redirection file for ssh too:

Set contents of ~/.gnupg/S.gpg-agent.ssh to:
%Assuan%
socket=${HOME}/.gnupg/S.gpg-agent.ssh-${HOSTNAME}

BTW, I just commtied the missing chnages to dirmngr and scdaemon.

For easier debugging you set a log file for gpg-agent or even better set that
log file to a socket in gpg-agent.conf
log-file socket:////home/foo/.gnupg/S.log
and the run
watchgnupg --time-only --force /home/foo/.gnupg/S.log
in another xterm.

Commit f1c3eb4 fixes this.

Hi again -

Exporting HOSTNAME worked, thanks.

I'm still not seeing a per-host ssh agent socket, though. Maybe i'm missing
something, but here's exactly what i'm doing:

Set contents of ~/.gnupg/S.gpg-agent to:
%Assuan%
socket=${HOME}/.gnupg/S.gpg-agent-${HOSTNAME}

(newlines after each of the two lines)

~/.gnupg/gpg-agent.conf contents:
enable-ssh-support
default-cache-ttl 7200
max-cache-ttl 14400
default-cache-ttl-ssh 7200
max-cache-ttl-ssh 14400
no-grab

gpg-connect-agent --verbose /bye

gpg-connect-agent: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: connection to agent established
gpg-connect-agent: closing connection to agent

Now i have gpg-agent running, and gpg works as expected.

In ~/.gnupg i see the following sockets:
S.gpg-agent-mymble
S.gpg-agent.ssh

Is the ssh agent socket supposed to be the same filename with .ssh appended, or
is there another line i should be adding to the S.gpg-agent redirect file?

Thanks!

On my system HOSTNAME is not an exported envvar. Thus

export HOSTNAME

should do what you want. ssh support and the new --extra-socket all use the
same code for creating the socket, thus this hould work. I have not tested it
but I am pretty sure. A problem might be that the printed SSH_AUTH_SOCK is not
set to the real socket name - I have not checked this.

I confirm what said by aheinecke. The bug is still there with 2.1.1-beta45 on my
system too.

Looks like a good solution. I got the git versions compiled and gave it
a whirl. I noticed a couple of things:

Looks like a good solution. I got the git versions compiled and gave it
a whirl. I noticed a couple of things:

I tried the exact contents of S.gpg-agent you gave below, but libassuan
is creating the file as $HOME/.gnupg/S.gpg-agent-

In other words the ${HOSTNAME} is blank, which obviously won't work out
very well. :) Presumably a bug. I checked my setup:

echo $HOSTNAME

mymble

hostname

mymble

So the hostname does appear to be set correctly. I'm not quite sure how
i can start it with --verbose to see if it helps show what's happening;
if i try that, with or without a server running it just gives me the
server status.

Second, with --enable-ssh-agent, i noticed that the ssh-agent socket is
still created as ~/.gnupg/S.gpg-agent.ssh. Will this same method be
able to specify a per-host ssh-agent?

In general, though, this looks like it's on the right track! Let me
know if i can do any more testing to help.

If you use the latest Libassuan and GnuPG from GIT you should get what you want.
For example:

rm ~/.gnupg/S.gpg-agent || true
printf '%%Assuan%%\nsocket=${HOME}/.gnupg/S.gpg-agent-${HOSTNAME}\n' \

      > ~/.gnupg/S.gpg-agent

Creates a redirection file which uses HOME and the HOSTNAME. If you start
gpg-agent with --verbose you get a noticed about what has been redirected.

Needs to be implemented for scdaemon and dirmngr as well - but that needs to
wait until Monday.

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)

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.

As I wrote in T1774 (aheinecke on Nov 27 2014, 05:42 PM / Roundup)
I reproduced this Bug with 2.1.1-beta45

Can you test it with the latest git version or the beta at
ftp://ftp.gnupg.org/people/werner/scratch/gnupg-2.1.1-beta35.tar.bz2
?

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)

I've opened T1775 and only afterwards noticed that this issue did aleardy
exist ;-)

So here is my mesage from T1775 which further qualifies this issue:

This bug was reported by fersingb on IRC, I could reproduce it.

If you have a public keyring in the .kbx format exporting a key with the full
keyid produces an endless output stream.

To reproduce it I can import any key into a newly created gnupg homedir.
When exporting this again using the fingerprint as identifier the bug is triggered.

My usual gnupghome was automatically migrated still has a pubring.gpg and works.

Setup:
FAKEHOME=$(mktemp -d)
gpg2 --armor --export CA308D95A6332F7056B4DFD194F78CF1265059CD | gpg2 --homedir
$FAKEHOME --import

Triggering the bug:

gpg2 --homedir $FAKEHOME --armor --export CA308D95A6332F7056B4DFD194F78CF1265059CD

The short fingerprint works:

gpg2 --homedir $FAKEHOME --armor --export 265059CD

My current version is yesterdays master (2.1.1-beta45) but the original reporter
used gnupg-2.1.0.

Ah damn,..
Duplicate of
T1774

sorry.

Duplicate of T1774

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.

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

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

Thanks for noting.

it is about the time to change the default behaviour and to have 2.1 install
gnupg.7 and 1.4 not to install it. Obviously there is a conflict for all
released versions of 1.4 but we can't do anything about it. I fear you have to
live with this minor conflict.

Fix pushed to the 1.4 branch.

backported to 2.0 and 1.4.

Does this now also work for you?

Yes. Thank you.

fixed with f80c2dd.