No response.

No response.

So this is basically 0what GNOME does with its keyring daemon and pinentry-gnome.

Btw, this was envoy: https://github.com/vodik/envoy

what I mean by unlocking is the act of using the passphrase to load the gpg and ssh keys and hence not needing to tip the phrase again afterwards.

I don't understand what you mean by unlocking gpg-agent. Can you please explain in detail what you try to achieve.

This works in recent 2.1.x versions, so let's close this here. 2.0.x is going EOL soon and won't get non-critical changes.

gnupg uses LC_ALL, LC_MESSAGES, LANG and the system default determined with GetThreadLocale() on Windows. Can you please check if you have set any of these environment variables?

Without the necessary info, we can not act on this.

Addition 2 [Workaround]:

when I run tail -f agent,log while executing the echo command these are the last lines that are printed to the file before the wait:

What version of GnuPG are you using? Standard upstream or from a distribution?

Well, I closed it as invalid because werner asked for more info a year ago and there was no response (at least none that made it into the bug tracker). If there is still an issue, maybe you can describe it in more detail and reopen the ticket. Thanks!

Oh, this has been fixed? Sorry, i don't think i got any message from this, i have changed my e-mail address now.

No feedback for 2 years.

No response for years.

Which tool did you use: gpg or gpgsm? <== In-house developed Web Service that call gnupg to decrypt or encrypt

Please be so kind and explain in more detail what you did.

2.3.3 of gpg4win

1.4.0 of gpgol

Which version of gpgol (or Gpg4win) are you using?

The debug log includes communication between host PC and the reader, thus, it may include your input of PIN when you do that.

Ping? Otherwise I would provide the required information.

Thanks, gniibe, for the quick reply.

Thanks for your explanation. Now, I got it.

Thank you for reporting. Sorry, I couldn't understand some part of your report. Perhaps, due to some terminology.

There are four things: primary key public, subkey public, primary key private, and subkey private.

not sure if that should be called closed as described here https://dev.gnupg.org/T3029
"This is no a bug but a non-proper installation of libgcrypt. In fact the output
of libgcrypt's "make install" shows hints on how to finish the install; also
pointing to ldconfig.

Thank you for reporting. Sorry, I couldn't understand some part of your report. Perhaps, due to some terminology.

Cool. Thanks for your work here. Where would I apply this patch, or should I just wait until you guys have it fixed?

Thanks a lot!

Thank you for additional info.
gpg --recv-keys can fail when we have network problem or dirmngr doesn't work well.
I think that the failure of your original report is that it goes something wrong when it merge keys into existing keys.
It helps me if you have the pubring.gpg BEFORE you invoked "pacman-key --refresh-keys".

I went through and was receiving keys individually just to see if it would work, and all of them work, except the:

Odd. I used the pubring.gpg you uploaded.
Refresh-keys successfully retrieve keys like:

That is the one I uploaded...

Thanks. But it's wrong keyring, I suppose. What we need is not your own public keyring, but the public keyring which pacman uses.
IIUC, please upload the one in /etc/pacman.d/gnupg.

I tried what you listed above and it worked, just like you said. I have uploaded my public keyring to look at. But other users are having this problem as well. Thanks.

Could you please give us more information so that we can locate the issue?
I did following, but I can't replicate the problem.
(1) Save 91 of key fingerprints listed in your log to a file (arch-keys.txt). From B61DBCE10901C163 to AF7EF7873CFD4BB6
(2) Make a new directory (arch-test).
(3) Run a command

$ gpg --homedir=arch-test --recv-keys $(cat arch-keys.txt )

This bug is not reproducible for me. I don't think it is Yubikey specific.
I suspect some failure for the transition from 2.0 to 2.1.
In GnuPG 2.1 the private keys are stored under the directory gnupg/private-keys-v1.d.
Do you have this directory?
How does it goes when you prepare another directory and specify that?
I mean:

mkdir SOME-NEW-DIRECTORY
gpg --homedir=SOME-NEW-DIRECTORY --card-status

Hi,

I am using systemd-resolved. It is listening on localhost UDP.

Did you changed --default-cache-ttl or --max-cache-ttl to zero or another small
value? The multifile feature requires that the passphrase cache has been enabled.

No reply to my question, thus it seems not to be important. Closing.
Note that replying to this will re-open the bug.

ping (see T2370 (wk on Nov 18 2016, 08:44 AM / Roundup))

Yes, I have seen that URL but what I like to get an answer to my question here
or on gnupg-devel. I do not want to follow a possible long thread of some Linux
distribution.

There was a long drawn out discussion as to the validity of "-hardfloat" in the
triplet name. You can peruse at https://bugs.gentoo.org/show_bug.cgi?id=584052 .

I am not a dev and have pretty much given up. The Gentoo devs are adamant that this
is an upstream problem.

ping

The difference (according to the gpg agent log) is that gpg v1 is obviously caching
the decrypted private key used to decrypt the files using the option "-d --
multifile" whereas gpg v2 in my case repeatedly requests the decryption of the
private key for each single file. Any way to change that?

Not quite true. As soon as a blocking system cal is used another thread is
scheduled. Long running operations like generating a new key may indeed take a
long time and inhibit other threads from running. They run long becuase they
need to collect entropy. Having other threads running at that time would not
really be helpful. Using gpg-agent for more than a decade now, I never made
that experience.

The more likely reason for the problem is that no working pinentry is installed
and the boths threads are waiting for the pinentry (pinentry access is obviously
serialized).

We need a log file from gpg-agent: Out this into gpg-agent.conf

log-file /tmp/foo/agent.log
debug 1024
verbose

and restart the agent.

In gpg-agent, only a single thread of execution runs at a time. So it is
entirely possible that what you are describing happens. For us to debug it, we
need a very concrete example. Please provide us with the command line(s) that
you are using to decrypt the files in parallel. Also, please list the keys. (A
small guess: you are using 16k RSA.)

I just tried:

$ g10/gpg --encrypt -r samuel </dev/urandom >/dev/null

As expected, the gpg process eats a lot of cpu time, and I can spawn two of them
just fine. This works with both my build as well as gpg from Debian testing.

I'm closing this bug due to inactivity. Feel free to reopen it with more
information.

Well, I can only say right now that since upgrading to Ubuntu 16.10, the gpg
command now is gnupg v2 by default, and my parallel decryption using
multiple gpg processes does not work any more. "Not working" means there is
only one gpg-agent processes using any CPU at all, and it is using only one
CPU core at 100% for a very long time. Nothing else pops up in top regarding
CPU usage. 75% of the CPU cores remain idle. So my guess is that the gpg-
agent does all of the work and therefore prevents multiple parallel
executions. My conclusions seem pretty obvious to me. But maybe it has to do
with stuff done by some downstream debian or Ubuntu packagers?

Hello,

I'm using RedHat Linux which already had a version of GnuPG installed. (2.0.14)
I'm not sure what process was used to install it. I downloaded the latest
tar-ball of GnuPG Stable 2.0.30 and installed it as per the process described in
the "HOW-TO". But when I check for the version using gpg --version, it gives me
the older version 2.0.14 instead of 2.0.30. Also , there were no errors while I
installed 2.0.30 either in compilation or installation. I'm not sure why the
--version command is still displaying the old version then.

ping

I tested with 2.0.22 on Ubuntu 14.04.5 LTS and SIGHUP expired the cached
passphrase. I'll have to find some time to test 2.0.30.