Fixed with nPth 1.3.

Fixed in 1.3.

Fixed with nPth 1.3.

Fixed in STABLE-BRANCH-2-0 branch of git repo, as of the commit:
5c599e4f6edd288f4759c9fc2bcf9fe87dee1836

Thank you for your report.
In 2.1.x, I fixed scdaemon so that card removal works fine.
I'll backport to 2.0.

It seems that it's related to ADNS.
I fixed error handling in the commits of 8a9341b and 6f1d812, so that correct
error from adns_synchronous will be logged.
I mean, the error message of "DNS query failed: System error w/o errno" will be
improved with correct error value.

Fixed in: 4e4843e735f32b5e79a51d8062da55bfaab6ad77
Please test.

Right. It is the cause.
Fixed in: 836b72363168cbb0051fc2356f61788468db211c

Fixed in: 98bc6f480ac973dccce90378dc021a2e24e58704

Thank you for your fixes and the specific test case.
Indeed, it's a bug.
I'm going to apply changes, but I think that it's better to have same code
pattern of g10/seskey.c (the part of verification).

Updated by the fix:

f9e49c8 scd: Fix an action after card removal.

Fixed in master.

f9e49c8 scd: Fix an action after card removal.

I confirmed that it's a regression in 2.1.15.

Fixed in master:

    8fe8105 scd: Release the card reader after card removal.

In my environment, it works both for PC/SC and in-stock CCID driver.

Not yet for 2.0 and 1.4.

FYI.

https://lists.gnupg.org/pipermail/gnupg-devel/2016-August/031479.html
^-- In this experiment, I tried another half of supporting OpenSSH certificates.

I found that it doesn't work as I had thought.

I think that the lower level support of gpg-agent is ready to add this feature
of accepting OpenSSH certificates, but modification of OpenSSH will be required
too, so that it works well.

Currently, the OpenSSH certificate file itself is still needed even if ssh-agent
supports OpenSSH certificates. When it returns a certificate to ssh client, ssh
client only uses the information of the key in the certificate. It is the file
which ssh client uses communicating to the server.

Scdaemon grabs the device after its first use; it gets information on the
card/token and it operates (sign/decrypt) based on those information. If it
releases the device, it should get the info.
Current design of scdaemon is state-full: it caches the information on the card
so that operations can be soon done.
more state-less design could be possible, with the cost of each operation will
be heavy (by getting information each time).

I don't know the PIV app of Yubikey, but, in most cases, such an app can be
written stopping scdaemon beforehand (by a line of gpgconf --reload scdaemon, if
it's a script). It's a simple workaround for now.

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.

I confirmed on AIX 7.1 with GCC 4.8.1, libgcrypt 1.7.2 builds well. "make
check" goes success with no errors.
I'm closing this again, because the particular problem of typedef has been fixed.
If you have another issue, please open another report.

This particular problem of assertion error, it was fixed in 1.22. So, I close this.
We also have T2378 for a possible change for Solaris/sparc. Please continue
there.

I believe that it's fixed in 1.22. Closing.

Closing, as I confirmed that -lrt is not needed any more in Solaris Userland
project:
https://hg.java.net/hg/solaris-userland~gate

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.

It is handled in scdaemon (not in g10/keyedit.c).

When the keysize is different, it changes key attribute automatically.
For 2.1, it was fixed by f10b427d0e2be333776fee2df8150145da36e587 on 2015-09-07
which is in 2.1.8.

For the T2238, it was backported in effect (not intentional, though).

1.4: ca1fc59
2.0: 1c15136

You are welcome. If my bad English makes it difficult, here is another document.

http://web.monkeysphere.info/doc/trust-models/
You can find the explanation:

So "full" ownertrust on a key is only meaningful as long as there is a trust
path to some User ID on that key already. "ultimate" ownertrust is meaningful
anyway, because presumably you control that key.

Adding "ultimate" trust means: you are specifying it's your own key. GnuPG
doesn't check if your own key is signed by another your own key (or you really
have corresponding private key).

Let me explain the validity of public keys.

• Start with a set of key(s) with "ultimate" trust. Ultimate keys are all valid,

put them to a set of valid keys.

• Pick a key from valid keys. Collect all keys signed by this key (locally or

globally), it's all valid. Put them to a set of valid keys.

Next, it checks "full" or "marginal" trust to a public key.

• Start with the set of public keys which are valid (by the computation so far).
• Pick a key from the set. If it has "full" trust, mark all keys which are

signed by this key as it's reachable by "full" trust.

• If it has "marginal" trust, mark all keys which are signed by this key as it's

reachable by "marginal" trust adding a point.

• Scan all marked key. If it can be reachable by "full" trust. It will be in

the set of valid keys. If it can be reachable by "marginal" trust by 3
(default) different keys, it will be also in the set of valid keys.

• Add checked keys to the set of valid keys. And apply(repeat) this procedure

recursively, to the newly added valid keys. Don't repeat too far. Stop if it
goes 5 (default) times.

In other words, adding trust (by --edit-key) to a valid key makes it possible
for another key to be validated by that key. Adding trust (by --edit-key) to an
invalid key doesn't make that invalid key valid. (If it's "full" or "marginal".)

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.

There are two different concepts: trust and validity.

It makes nothing when you edit a key to mark "full" trust which has unknown
validity. (A key's validity should be valid.)

Marking trust (full or marginal) to a valid key makes validation of other keys
will be possible by that key.

In the beginning, you can make a key valid by signing (sign or lsign) by your
ultimately trusted key.

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?

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.

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.

Fixed in the repo STABLE-BRANCH-1-4.
Forward ported to STABLE-BRANCH-2-0.
It's not in master (2.1).

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.

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

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.

Thank you for your report. Please give us more information.
Please show us the failure message, so that we can fix.

It seems that it's the bug of libgcrypt.
https://lists.gnupg.org/pipermail/gcrypt-devel/2016-June/003901.html

Fixed in 2.1.13.

I think that it requires GCC version 4.6 or later for AVX instruction.
4.9 or later is better.
Ideally, configure should check GCC version.

uldis: Thanks for your comment. Let me show my opinion.
There are three ways (at least) to create a semaphore.
Each has different semantics, how it can be shared among different processes.

(1) sem_init with pshared=0: Not shared among processes
(2) sem_init with pshared=1: Shared among children processes of particular parent
(3) sem_open: Shared among any processes (with relevant permission)

For AIX, npth doesn't work well with (1). You suggested (3), while I proposed (2).
It is true that (2) and (3) would open up some attack vector(s),
but I believe that (2) is smaller, if any.

Sorry, my near sight. I only fixed cofactor support, in a case where "h" is
provided.
I should have fixed other parts, too. Now, I fixed in master:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=0f3a069211d8d24a61aa0dc2cc6c4ef04cc4fab7;hp=fa917d2e24b0c98143a079ab4889ad8f69bee446

It is backported to 1.7 branch too.

libaacs should work with this patch.

I think that for this particular use case of gnupg with external keyring, the
expected usage doesn't need to use trustdb at all. In such a case, we can use
--trust-model always (like gpgv), or we can use gpgv.
Then, original problem is gone, since it doesn't touch trustdb.
Anyway, fixing a race condition is good thing.
Note that there are more race conditions left, but those can be only triggered
by multiple processes accessing trustdb and a process is writing to trustdb.

For a particular hash table race condition, it is
fixed in master which will be released as 2.1.13.
Fixed in the repo of 1.4 and 2.0.

D372: 847_libgpg-error-20160613.diff