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.

Ok, I can record such files. Will there be any confidential information contained in
these logs?

AIX required a patch for Npth library for fork.
Please test again with npth 1.3 when it will be released.
I tested with 2.1.14, all go well successfully (make check no errors) with
patched version of Npth library.

I confirmed that with patched npth, 2.1.14 with
c49c43d7e4229fd9f1bc55e17fa32fdc334dbef6 builds well and "make check" goes
successfully (on AIX 7.1 with gcc 4.8.1).

Please test again when npth 1.3 will be released.

You can have a configuration file like:

.gnupg/gpg-agent.conf

enable-ssh-support
debug-level guru
debug-all

log-file /run/user/1000/gpg-agent.log

and

.gnupg/scdaemon.conf

debug-level guru
debug-all
debug-ccid-driver

log-file /run/user/1000/scd.log

so that the interactions can be recorded with debug information.

In T2403 (gniibe on Jul 13 2016, 10:53 AM / Roundup), I said wrongly. It's tests/Makefile.in.
Here is tests/Makefile.am modified.

Attached is modified Makefile.in, so that 'make check' can run t-fork test program.

Yes - I install the patched Npth library into the System. Can you please give
me the expected tests/Makefile.in and tests/Makefile.am.

Please manually edit tests/Makefile.in and tests/Makefile.am, so that you can
compile and run t-fork test program.
Have you install the patched Npth library into the system, so that you can use
patched Npth library with GnuPG?

Yes - I install teh patch and build the Npth library.

make check

Making check in src
make[1]: Entering directory '/develop/npth-1.2/src'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/develop/npth-1.2/src'
Making check in tests
make[1]: Entering directory '/develop/npth-1.2/tests'
make check-TESTS
make[2]: Entering directory '/develop/npth-1.2/tests'
PASS: t-mutex

PASS: t-thread

All 2 tests passed

make[2]: Leaving directory '/develop/npth-1.2/tests'
make[1]: Leaving directory '/develop/npth-1.2/tests'
make[1]: Entering directory '/develop/npth-1.2'
make[1]: Leaving directory '/develop/npth-1.2'

Thanks a lot.

5636336: 23330877: sem_post(0xF1299434) Err#13 EACCES

This is the problem.
Did you really got success by "make check" of Npth library?
Have you installed the patched Npth library?
Please confirm.

5636336: 23330877: sigprocmask(2, 0xF02E6968, 0x2FF1E3E0) = 0
5636336: 23330877: _sigaction(31, 0x2FF1E438, 0x00000000) = 0
5636336: 23330877: thread_setmymask_fast(0x00000000, 0x00000000,
0x00000000, 0x1164003D, 0x0001F0B0, 0x00000000, 0xE0283800, 0x00000000) =
0x00000000
5636336: 23330877: sigprocmask(2, 0xF02E6968, 0x2FF1E3E0) = 0
5636336: 23330877: _sigaction(2, 0x2FF1E438, 0x00000000) = 0
5636336: 23330877: thread_setmymask_fast(0x00000000, 0x00000000,
0x00000000, 0x1164003D, 0x0001F0B0, 0x00000000, 0xE0283800, 0x00000000) =
0x00000000
5636336: 23330877: sigprocmask(2, 0xF02E6968, 0x2FF1E3E0) = 0
5636336: 23330877: _sigaction(15, 0x2FF1E438, 0x00000000) = 0
5636336: 23330877: thread_setmymask_fast(0x00000000, 0x00000000,
0x00000000, 0x1164003D, 0x0001F0B0, 0x00000000, 0xE0283800, 0x00000000) =
0x00000000
5636336: 23330877: thread_setmymask_fast(0x60004003, 0x00000000,
0x00000000, 0x0000D032, 0x0001F0B0, 0x00000000, 0xE0283800, 0x00000000) =
0x00000000
5636336: 23330877: sem_post(0xF1299434) Err#13 EACCES
5636336: 23330877: kwrite(2, " A s s e r t i o n f a".., 18) = 18
5636336: 23330877: kwrite(2, " _ _ E X", 4) = 4
5636336: 23330877: kwrite(2, " , f i l e ", 8) = 8
5636336: 23330877: kwrite(2, " n p t h . c", 6) = 6
5636336: 23330877: kwrite(2, " , l i n e 1 4 9\n", 11) = 11
5636336: 23330877: kfcntl(1, F_GETFL, 0x1164003D) = 67108865
5636336: 23330877: kfcntl(2, F_GETFL, 0x1164003D) = 67108865
5636336: 23330877: _getpid() = 5636336
5636336: 23330877: thread_kill(-1, 6) = 0
5636336: Received signal #6, SIGABRT [default]
5636336: * process killed *
6815982: 16842893: thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000,
0xD0551900, 0x00000000, 0x1101008D, 0x1101008D, 0x00000000) = 0x00000000
6815982: Received signal #20, SIGCHLD [default]
6815982: 16842893: close(3) = 0
6815982: 16842893: sigprocmask(2, 0x20003AC8, 0x00000000) = 0
6815982: 16842893: __loadx(0x04400000, 0x2FF22080, 0x00000800, 0xD05516A4,
0x00000000) = 0x00000000
6815982: 16842893: kfcntl(1, F_GETFL, 0x1101008D) = 67110922
6815982: 16842893: kfcntl(2, F_GETFL, 0x1101008D) = 67110922
6815982: 16842893: _exit(0)

Thank you for your testing. The patch is to the repository. You need manual
edit to tests/Makefile.am which add t-fork as a test program. I think that
"make check" should go successfully for Npth with the patch.

Could you please trace the gnupg-agent with children processes?
If you are using truss, -f option (follow childres), please.

When I apply the patch:

patch -p1 -i npth.aix.patch

patching file configure.ac
patching file src/npth.c
patching file tests/Makefile.am
Hunk #1 FAILED at 40.
1 out of 1 hunk FAILED -- saving rejects to file tests/Makefile.am.rej
patching file tests/t-fork.c

1. cat tests/Makefile.am.rej
   • 40,45 **** AM_CPPFLAGS = -I../src -D_POSIX_C_SOURCE=200112L AM_LDFLAGS = LDADD = ../src/libnpth.la $(LIBSOCKET) $(LIB_CLOCK_GETTIME) endif noinst_HEADERS = t-support.h
   • 40,46 ---- AM_CPPFLAGS = -I../src -D_POSIX_C_SOURCE=200112L AM_LDFLAGS = LDADD = ../src/libnpth.la $(LIBSOCKET) $(LIB_CLOCK_GETTIME)

+ TESTS += t-fork

  endif

  noinst_HEADERS = t-support.h

I make the lib and compile gnupg but the gpg-agent don't start and the tests
failed.

#/develop/gnupg-2.1.13/agent/gpg-agent --version
gpg-agent (GnuPG) 2.1.13
libgcrypt 1.7.1
Copyright (C) 2016 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.

But the Agent dont start as daemon.

statx("/root/.gnupg/S.gpg-agent", 0x2FF22848, 76, 0) Err#2 ENOENT
bind(3, 0x20013A38, 26) = 0
chmod("/root/.gnupg/S.gpg-agent", 0700) = 0
listen(3, 5) = 0
kfcntl(0, F_GETFL, 0x111D00E9) = 67110922
kfcntl(1, F_GETFL, 0x111D00E9) = 67110922
kfcntl(2, F_GETFL, 0x111D00E9) = 67110922
sigprocmask(0, 0xF02E6968, 0xF02E6970) = 0
kfork() = 5767248
thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0xD0551900,
0x00000000, 0x111D00E9, 0x111D00E9, 0x00000000) = 0x00000000

Received signal #20, SIGCHLD [default]

close(3) = 0
sigprocmask(2, 0x20003AC8, 0x00000000) = 0
__loadx(0x04400000, 0x2FF22080, 0x00000800, 0xD05516A4, 0x00000000) = 0x00000000
kfcntl(1, F_GETFL, 0x111D00E9) = 67110922
kfcntl(2, F_GETFL, 0x111D00E9) = 67110922
_exit(0)

Thank you for your checking of libs.
Failure of gpg-agent causes many errors.
One possible cause of gpg-agent's error is Npth. I have a patch for AIX:
https://lists.gnupg.org/pipermail/gnupg-devel/2016-June/031264.html

I'm pushing this change today to Npth repository.

There isn't an NFS file System on the Server.
It's possible that the lib's have issues but I compile the requsite lib's new
and I receive no Errors when I run the Tests.
I think the LIBPATH is OK, e.g. ./g10/gpg can find all lib's:

ldd ./g10/gpg
./g10/gpg needs:

/usr/lib/libc.a(shr.o)
/usr/lib/libpthread.a(shr_xpg5.o)
/usr/local/lib/libgpg-error.a(libgpg-error.so.0)
/usr/lib/libintl.a(libintl.so.1)
/usr/local/lib/libgcrypt.a(libgcrypt.so.20)
/usr/local/lib/libassuan.a(libassuan.so.0)
/usr/lib/libbz2.a(libbz2.so.1)
/unix
/usr/lib/libcrypt.a(shr.o)
/usr/lib/libpthreads.a(shr_comm.o)
/opt/freeware/lib/libgcc_s.a(shr.o)
/usr/lib/libiconv.a(shr4.o)

I looked T1779, and it failed just like this
report, with an NFS-v3 mounted file system.
Socket to gpg-agent doesn't work if it's on NFS file system.

I think that your installation of libgcrypt, libgpg-error, etc. has some issues.
Please check the installation of libgcrypt, libgpg-error, etc.

You would need to setup LIBPATH environment variable, if it's not installed to
the standard place.

Reference:
https://www.postgresql.org/message-id/52EF20B2E3209443BC37736D00C3C1380A6E79FE%40EXADV1.host.magwien.gv.at

Yes - the HOME was / but I change it to /root and now I recieve the following
Output (only failed):
.
.
.
make[3]: Entering directory '/develop/gnupg-2.1.13/tests/openpgp'
version.test: starting the gpg-agent failed
FAIL: version.test

> Hash algorithm MD5 is not installed (not an error)

PASS: mds.test
FAIL: decrypt.test
FAIL: decrypt-dsa.test
FAIL: sigs.test
FAIL: sigs-dsa.test
FAIL: encrypt.test
FAIL: encrypt-dsa.test
FAIL: seat.test
FAIL: clearsig.test
FAIL: encryptp.test
FAIL: detach.test
FAIL: armsigs.test
FAIL: armencrypt.test
FAIL: armencryptp.test
FAIL: signencrypt.test
FAIL: signencrypt-dsa.test
FAIL: armsignencrypt.test
FAIL: armdetach.test
FAIL: armdetachm.test
FAIL: detachm.test
FAIL: genkey1024.test
FAIL: conventional.test

> IDEA FAIL: conventional-mdc.test

multisig.test: valid is invalid (sig_sl_valid)
FAIL: multisig.test
verify.test: verify of msg_ols_asc failed
verify.test: verify of msg_cols_asc failed
verify.test: verify of msg_sl_asc failed
verify.test: verify of msg_olsols_asc_multiple failed
verify.test: verify of msg_oolss_asc failed
verify.test: verify of msg_cls_asc failed
verify.test: verify of msg_clss_asc failed
verify.test: verify of msg_clsclss_asc_multiple failed
FAIL: verify.test
armor.test: the armored_key_8192 bug is back in town
FAIL: armor.test
import.test: ./bug894-test.asc: import failed (bug 894)
FAIL: import.test
FAIL: ecc.test
PASS: 4gb-packet.test
SKIP: gpgtar.test
use-exact-key.test: : import failed
FAIL: use-exact-key.test
FAIL: default-key.test

> D74C5F22 FAIL: export.test

PASS: finish.test

31 of 34 tests failed
(1 test was not run)

Please report to https://bugs.gnupg.org

Makefile:650: recipe for target 'check-TESTS' failed
make[3]: * [check-TESTS] Error 1
make[3]: Leaving directory '/develop/gnupg-2.1.13/tests/openpgp'
Makefile:773: recipe for target 'check-am' failed
make[2]: * [check-am] Error 2
make[2]: Leaving directory '/develop/gnupg-2.1.13/tests/openpgp'
Makefile:527: recipe for target 'check-recursive' failed
make[1]: * [check-recursive] Error 1
make[1]: Leaving directory '/develop/gnupg-2.1.13/tests'
Makefile:580: recipe for target 'check-recursive' failed
make: * [check-recursive] Error 1

If I understand correctly, you ran 'make check' by root and root's HOME is '/'.
It is unexpected by the test program. If it works with HOME=/root or some other
value, it's not real failure.