Oh, I' sorry - my fault. I searched in ...\GnuPG\bin instead of ...\gpg4win\bin

In T5250#143872, @kaie wrote:

It seems gpgme-json is intended to execute in the Web JavaScript sandbox of a browser.

no, that doesn't change anything.

Compiling now works, but I get the following linker errors:

I tried it - that doesn't help. Same error message.

I have now tried to build libgcrypt 1.9.0 for arm64 using clang. I get the following error:

In fact, Thunderbird does not use gpgme-json, but loads the gpgme shared library at runtime. The interesting thing is that Thunderbird works fine if gpgOSX is used.

OK, then we'll have to live with --disable-asm until the next major version is released, or switch to gcc.

In T5157#139622, @gniibe wrote:

ARM64 has been only tested on platforms which support ELF.

While it doesn't looks good (using AMD64 even if it's ARM64), I think this patch should be applied:

diff --git a/cipher/asm-common-aarch64.h b/cipher/asm-common-aarch64.h
...

Yes, I did. Identical result.

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:

I agree that this is a tricky problem, but it should really be improved.

I did not yet implement the use of "key origin" in Enigmail. I don't believe that it adds much value, because I anyway need to track more details about autocrypt keys separately from the keyring (such as the peer-state).

I could reproduce the problem (by chance) now, because I started a VM I didn't use for a while:

Could it be possible that it's a 32/64 bit issue?

Is this with the /MINIMAL flag?

I have changed visibility of the bug, as I think you can do a lot more with this than Marcus imagined.

This looks similar to the "multiple plaintext" issue that we had in Feb. / March 2007.

It turned out to be a bug in Enigmail. The "," in the key list s wrong.

Werner, so what do you suggest? Does Enigmail (and any other tool using gpg, and actually also across tools) need to make sure that there are no concurrent calls to gpg of the type that could lead to adding a new key in the keyring?

It looks like this was on my side. I can't reproduce it anymore; in other words dirmngr survives changes to DNS servers now.

You're right, stat() works correctly. I created a small tool that implements the same logic. For some reason dirmngr is still not able to find the DNS server after suspend/resume in combination with changed locations. I still get "no route to host" errors.

yes, it's the official binary release from ftp.gpg4win.org.

That's gpg2 2.0.12, installed as part of gpg4win 2.0.1 (binary version installed).