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.

Main topics:

• D473: Introducing LDADD_FOR_TESTS_KLUDGE to enable 'make check' with LD_LIBRARY_PATH
  • Done for libgpg-error (for forth coming 1.34)
  • I am now applying to libgcrypt (for 1.9) and gpgme
• {D471}
  • OK to apply to libgcrypt?
  • For GNU/Linux, use the new macro getrandom keeping same abi of syscall (no extra audit of glibc implementation)
  • Use getentropy if OS has for other operating systems like FreeBSD and OpenBSD

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.

• Fixed this event editing by "Edit Recurrence"

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.

Last week:

• Gnuk 1.2.13 release following
  • Chopstix 1.13
  • FST-01SZ PCB design (tagged 3.01)
• Finalize the production of FST-01SZ
• Trying to purchase metal case which can be attached to FST-01SZ:
  • This one has built-in hole to show LED light: https://item.taobao.com/item.htm?id=550180089286
• Accounting

This week:

• Mostly off for new year gatherings

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.

In Streatch, 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.

Thanks for your information.
Hum, you are using gpg-agent for SSH access.

Perhaps, it's better to remove -no-install flag in tests/Makefile.am, so that test programs will be wrapper script by libtool.

It seems it's Ubuntu specific: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1796563

I think that all that we can do is to improve documentation.

Apparently, it's an error from your installed /usr/local/opt/libgpg-error/lib/libgpg-error.0.dylib (you have some configuration to prefer this library), while your configure is for /usr/local/lib (because you specify no --prefix).

Please let us know the version of GnuPG, the output of gpg --card-status when inserted, and how gpg is not working well, etc.

How scdaemon responds when there is no card available?

Last week:

• Finished FST-01SZ design (tagged release/3.0.1), confirmed production
• A bug fix in master for decryption checking smartcard keys: rGebf775eb16fe: card: Suppress error message by agent_scd_cardlist.
• Re-evaluate T4281: Backport smartcard support changes to 2.2
• My problem for ack button was found a hardware issue: unstable USB connection results USB Reset

In FreeBSD, getrandom(3) became available, when getrandom(2) was added. <-- This is my theory.
If this is true, just use getrandom(3), not using getrandom(2) by syscall.

It became common, because many people now use larger keys.
For RSA-4096, three simultaneous connections for decryption may cause the failure.
In the experimental patch of D472: Limit active connections for gpg-agent, I limit gpg-agent to accept two connections only.

increment the counter is better done by the looping main thread.

This is an experimental patch. So, I just reuse SIGUSR1 to wake up "select"-ing thread by kill(2).
I put limit-active-connections 2 in gpg-agent.conf for the test with run-threaded of gpgme.