I don't see a reason backing off the original commit. A fix for macOS is now available (rCfa21ddc158b5) and will be in the next release. No reason for other changes.

Closing. A small change in Kleopatra (T6472) should help to avoid using this hack in common cases.

Why can't we keep the signed int? Do we ever need such a long timeout. We could for example define -1 as use default timeout.

This has been fixed for gnupg24 and gpg4win.

!ebo: Did you set a log-file into gpg.conf or common.conf ?

That is basically the key signing party scheme we developed at the keyserver convention in Utrecht in 2000. Sometimes also known as Sassaman or over-the-lunch protocol. Gnupg used to come with a tool named ring-a-party which did the paperwork. However, experience has shown that it is too hard to explain and get right - even to key signing party geeks.

Funny enough that Python seems not to allow to set the permission with open. Low priority because a proper umask must anyway be used on a multi-user system.

There is still a buglet because in some modes the weak key error can be swallowed by other errors. A fix would be something like:

I wonder why github did not automatically closed this pull request - after all exact that patch was commited.

Okay, that was easy to check.

Not easy to fix because gpg --card-edit/-status has some support form other cards. Eventually these commands will be replaced by gpg-card. In the meantime we can use this hack:

@gniibe, will you be so kind an check the provided patches

To replicate the problem it is best to use Windows. Should be solved with my commit. Note that the bug is specific to 2.4 dues to irts multi-card and app support. There was no problem on 2.2.

The actual error is in gpgme. CreateProcess is called with "gpgtar" but "gpgtar.exe" must be used.
This has been fixed with commit rM0c29119e061c. The reason why we didn't noticed the real cause of the problem is that the CreateProcess error shows up in the gpgme-w32spawn helper which has no good way for returning errors.

In T6451#169608, @gniibe wrote:

Reading the commit rC5beadf201312: Add gcry_cipher_ctl command to allow weak keys in testing use-cases,
The test code in basic.c assumes that it is an application responsibility to confirm&ignore GPG_ERR_WEAK_KEY error when using GCRYCTL_SET_ALLOW_WEAK_KEY.

Thanks for the report. Fix is easy. I only wonder why you want to use a weak DES key.

On Windows we always use --status-fd=1 but with gpg it is not a problem because we use a differenrt fd for output.

Unfortunately I can't replicate that with my Yubikey on 2.4.1. Tried several variant and with and without keyboxd. My Yubikey has PIV disabled but I doubt that this is the problem.

Actually Linux already returns ENOSYS on older kernels where there is no getrandom libc call. Thus returning ENOSYS if we don't have the libc version of that syscall (i.e. getrandom) in FIPS mode seems to be the Right Thing to do. My whole comment was about fips mode - it does not make much sense to enable FIPS mode if the system is not appropriate for it.

What about