Yes, I did. Identical result.

Why the hell do they that? The standard compiler on a system is called cc which may translated to whatever the system installs for it. gcc is a specific implementation with certain properties. Di you try CC=clang to override this?

And the arm64 cross-compiler:

Sorry, I forgot to mention that Apple ships a gcc-wrapper for clang. It just accepts gcc command lines parameters and translates them to clang parameters.
Here is the output of gcc --version:

You say that you build using clang but the log shows that you invoke gcc.

The problem is meanwhile solved. Thanks a lot
Heinrich

No more problems reported, so I assume like @aheinecke that it has been resolved in Windows.

We changed the fallback to utf-8 in 2.2 and 2.3 and thus this bug can be closed. On Windows there is still the problem with the command line. However, this is better tracked with T5038 and its related tasks.

Recall that each user has their own keys and configuration. This seems to be a general question on how to use GpgOL. Please use the help resources listed at gpg4win.org instead of this bug tracker.

Because the original problem of EAFNOSUPPORT has been fixed, I am going to close this bug.

It is likely that EPERM (Operation not permitted) occurs by a system call connect(2) if you have some firewall rule(s) which forbids network access.
The dirmngr use libdns resolver which directly connects name servers.
If this is the case, you can use `--standard-resolver\ to use system's standard DNS resolver instead.

On Debian, please see: /usr/share/doc/g++-mingw-w64-i686-win32/README.Debian

IIUC, the error occurred when Kleo is exiting and a destructor (in libKF5ConfigWidgets) is called with null pointer.

Version 3.1.14 released 2020-11-25
Kleopatra / GnuPG: Unicode home directories are now supported. (T5055)

Fixed in rDf810f0bc5b13: git.gnupg.org: Update entry page.

For ctx->exportPublicKeys returning 0 even when a failure, (with fix of gpg) error handling should be done differently.

Well, I fixed my loopback passphrase provider and the application no longer crashes with a bad passphrase.

Will be fixed with 3.1.14

Works, I've tested with Kleopatra.

relatively new feature

Yes. In the mean time, I'm using a cheap workaround : validate the input passphrase by signing a dummy text before exporting. Not that ugly and can stay for long.

More specifically, in the situation of multiple calls, ->getPassphrase is called multiple times, and it should return newly allocated "char *" object each time, because it is released each time (in lower layer).

My excuse: Please note that the support of exporting secret keys by GPGME are relatively new feature (see {T5046) and the fix rM3382ecb17eb5: core: Support exporting secret keys.). The fix of rM53ac732bae46: core: Call _gpgme_passphrase_status_handler when exporting keys. is a part of the support.
I think that we need more fixes for gpg/gpgme to be fully working well.

In T5151#139410, @gniibe wrote:

when passphrase is wrong, the passphrase callback is called more than one time (one for primary key, and another for a subkey, more if there are more subkeys).

Please use shorter password.
For gpgsm, maximum is 31 chars.

Currently, gpg doesn't report any errors to status line for exporting secret keys. If needed, a patch like this is needed:

Chasing this bug, I pushed a change: rM53ac732bae46: core: Call _gpgme_passphrase_status_handler when exporting keys.

Stable now and works as expected. Thank you!

Killing the daemon using gpgconf is fine if you are aware you need to do it. We weren't, and I suspect few other users would be either.

Removing 2.2 tag because it has been fixed in one of the last releases.

Its done for 2.2 thus changing the tag.

In T5151#139353, @nmset wrote:

Using Context::setExpire(), expiry time of keys and subkeys can be changed in a predictable way, with good and bad passphrase (fails with error of course).

Thanks.

Before step 2.d you should stop gpg-agent and other daemon

In T5151#139330, @ikloecker wrote:

I highly recommend to use the new ChangeExpiryJob instead of the fragile (and apparently buggy) edit interactor.

If you want to debug this, I suggest to use a logging socket. Put into all gpg-agent.conf files these lines:

In T5151#139332, @ikloecker wrote:

Can you try if using the overload

As for renaming "Change Reset Code" to "Set Reset Code", what about "Change PIN" and "Change Admin PIN"? Should they also be renamed? If not, why not? Is there no default reset code? Is there a way to find out whether the reset code has already been set (in which case "change" would be more appropriate than "set")?

You write

This does not work.

Can you be more specific? What doesn't work? Which OS, which version of Kleopatra, what smartcard are you using?

Can you try if using the overload

Error Context::exportPublicKeys(const char *patterns[], Data &keyData, unsigned int flags)

which takes an array of patterns instead of a single pattern also crashes?

Unless you need some special features of GpgSetExpiryTimeEditInteractor or you have to support gpgme <1.15, I highly recommend to use the new ChangeExpiryJob instead of the fragile (and apparently buggy) edit interactor.

Yes, it is due to a backport from master: rG1049f06c6d2e: scd:openpgp: Allow keygrip to be used to reference a key
Fixed in rG84020385be19: scd:openpgp: Public keys should be available for check_keyidstr..

I looked the gpg-agent.log, it indeed suggested the problem fixed in rG61aea64b3c17: scd: Fix the use case of verify_chv2 by CHECKPIN., which is included in 2.2.24.

Building and installing 2.2.24 at least made it not crash, the very least it's an improvement in that respect.

You have multiple readers and using PC/SC by specifying reader-port.
We fixed in master by T4998: scdaemon: PC/SC "No such device" without reader-port, and I didn't know similar fixes should be backported.
I will soon.

The problem seems to have returned in 2.2.24.

Thanks again for your report.

I'm still having problems with 2.2.24. Now the card removal is detected correctly, but the initialization fails.

We had some card related regressions in 2.2.23. I would appreciate if you could first test again with 2.2.24 which was released yesterday.

Resetting priority to normal for re-evaluation

Re-opening. Now trying to generate new keys fails with a "Wrong card" error.

Fixed. Workaround for gpgme 1.15 (and earlier) implemented in Kleopatra: Do not call setRemark() with an empty QString.

I think Kleopatra is affected. It calls setRemark() on the job unconditionally with the text from the widget, and I'm pretty sure that this text is empty but not a null QString, if the user doesn't enter a remark.

Ingo, can you please check? I guess we are not affected because Kleo already checks for an empty string. But dkg's suggestion sounds good to me.

Note that you actually run 30 independent processes with gpg 1.4 but with gpg-agent there is just one process to handle the private key operations (decrypt). To utilize more cores you need to setup several GNUPGHOME with the same private keys.

I think that it is not gpg-agent but pinentry which causes millions of futex syscall errors.
For interactive use case, pinentry may be the point of contention.
I might be wrong if your key is not protected by passphrase.

Indeed, I think this might be a driver problem.