Some of my terminology: I call "case", "shell", and "board".

Final fix was rG380bce13d94f: agent: Use clock or clock_gettime for calibration., with clock.
Closing this patch.

The metal case, I bought from here (it's expensive CNY3.00, for individuals): https://item.taobao.com/item.htm?id=550180089286

For prototype, I used:

• ZL-272 (without slits): https://detail.1688.com/offer/566273410945.html
• ZL-271, the metal shell: https://detail.1688.com/offer/566197153418.html

• Repository for PCB design: https://git.gniibe.org/cgit/gnuk/fst-01.git/
  • tag: release/3.01 is the latest for the design itself, but last commit 8ee4e0d53a73993e42d1c2ccc12b08757338f4b1 added data sheet for connector.
    • • The particular data sheet is for a variant of connector with slits.
    • in the output directory, I put additional information as well as the gerber output: https://git.gniibe.org/cgit/gnuk/fst-01.git/tree/output?id=8ee4e0d53a73993e42d1c2ccc12b08757338f4b1
    • In output/README.txt, there are information for procurement for the GD32F103 chip and ZL-272 connector.
    • But those are the ones I specified, and the actual vendors/distributors are different
    • For ZL-272 with slits, it seems that it's DongGuan Yuliang Electronics Co., Limited (http://www.dgyuliang.net) which provides the connector
• The test plan I specified is: https://www.gniibe.org/memo/development/fst-01/fst-01sz-testplan.html

When bogus entry is "", the error is GPG_ERR_NO_PASSPHRASE, and user cannot input the passphrase.

Confirmed that manually created entry in gnome-keyring-daemon causes trouble.

Since there is --mode=normal option, it should be --mode=ssh.

Thank you. I was waiting your feedback.

OK, I will add for OpenPGPcard 3.1 or later.

OpenPGPcard 3.1 or later supports clearing authentication status or examining the status.
The problem is that implementations don't use version number for available features.
Specifically, Gnuk keeps using version 2.0 in application ID, and only supports specific features of 3.3.

BTW, did you manually define -DNDEBUG, or what caused -DNDEBUG?

Reading https://en.wikipedia.org/wiki/Fedora_version_history, I guess that your kernel/glibc doesn't have working mlock.
It may work if running by root, though.

It is fixed in master branch of the repo.

OK, it's a libc with no pthread_rwlock_t.

T4298: 'make check' with uninstalled library, which is building now (even if rpath doesn't work well) handles related issue, which was fixed for libgcrypt-1.9. Since this issue is for other libraries (libgpg-error, specifically), we could do something similar, but, it may be detecting LD_LIBRARY_PATH to fail with "Please remove LD_LIBRARY_PATH".

Applied.

I think Bash 5.0 is in sid, not testing yet. Are you sure it's related to Bash 5.0? Is there any possibility your upgrading some other software causing this?

Done for libassuan and libksba.

Done for gpgme.

Done for libgcrypt.

Pushed to master, fixing about return value of getentropy. Tested on FreeBSD 12. Tested on FreeBSD 11 where getentropy is not available.

Done for libgpg-error.

Topic branch of libgpg-error is not good to show changes (for other libraries).
So, I made D473: Introducing LDADD_FOR_TESTS_KLUDGE to enable 'make check' with LD_LIBRARY_PATH.
Appliying to libgpg-error.

For other distros, it seems it's quite old issue: https://sourceware.org/ml/binutils/2012-05/msg00037.html

My patches on the topic branch: https://dev.gnupg.org/source/libgpg-error/history/gniibe%252Fdisable-new-dtags/

In my patch, for OpenBSD and FreeBSD (well, other than GNU/Linux), it uses getentropy if available. For GNU/Linux, we use the local macro of getentropy (regardless of the availability of the function), keeping exactly same behavior of syscall with __NR_getrandom.

Update to prefer syscall on GNU/Linux (no need to audit libc implementation):

My tentative conclusion: When (GNU) ld supports --disable-new-dtags, add it to LDADD in tests/Makefile.am.

Thanks a lot for your logs. I see what's going on here.
For some reason, Yubikey keeps running after failure by suspend/resume (perhaps, because it serves for multiple functionalities of USB HID for OTP, as well as CCID for OpenPGPcard).
This failure mode is not expected by the current implementation of scdaemon, under in-stock CCID driver.

The workaround in T3825 is for PC/SC driver. So, it is not the case for internal stock CCID driver.
'scd reset /bye' does not let the scdaemon do reset process of the card itself. It resets the transaction of scdaemon.

Please show us your output of gpg --card-status for each card, and tell us the reason why you think "the pgp db seems screwed up".

For my test, six distinct keys (three subkeys for each smartcard) works fine.
IIUC, you try to use same decryption key by two smartcards. Currently, it is not supported.

Is it an issue when you share an decryption key E among two smartcards?
I think that when there are six distinct keys (three subkeys for one smartcard each), it works fine.
I'll try to make reproducible test case.

This is mine:

Confirmed my theory of getentropy(3): https://reviews.freebsd.org/rS331279

Reading this discussion: http://lists.gnu.org/archive/html/bug-libtool/2018-01/msg00014.html
It seems that it could be fixed if we care about the order of libraries.
And it's not the issue for libgpg-error, which doesn't require external libraries.

For binutils, in Stretch, Debian specific patch was introduced.
Then, upstream introduced --enable-new-dtags option for configure to build binutils.
Now, Debian uses --enable-new-dtags option (at build time).

Basically, you are right. In addition, gpg-agent asks scdaemon about list of card/token.

sshcontrol entry is required for non-smartcard keys, but not for keys on smartcard. This is intentional. For gpg-agent and current format, it is only the information for gpg-agent to know if a key is for SSH or not.

OpenBSD uses getentropy(2). glibc (>= 2.25) has getentropy(3), too.

Applied to master.

I see your point. You are right. For SSH access, it just fails without asking insertion. It's not Windows specific.
I checked the change of history of gpg-agent, but I cannot find prompting insertion was supported.
So, I don't thin this is a regression.

For the correctness of rndjent implementation, I'm applying D461: jent random requires finalizer to deallocate secure memory.