We should not do this.

In T5130#139220, @ikloecker wrote:

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

AArch64 clang support was added to 'master' on 2018-03-28. One would need to backport commits 8ee38806245ca8452051b1a245f44082323f37f6...9b58e4a03ba3aeff7bae3f40da706977870c9649 to 1.8 branch.

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
...

Fixed in master. I will backport to 2.2.

I was wrong. Patch is being updated...

Thanks. Fixed in rM7a4fe82a017b: python: Fix key_export*..

So, I'm going to push D513 to both of 1.8 and master (to be 1.9).

It worked again, attaching the screenshot. Unfortunately had disabled the logging and hence no log info.

In T5163#139750, @werner wrote:

You better wipe ecc_d_padded or use xtrymalloc_secure.

You better wipe ecc_d_padded or use xtrymalloc_secure.

Here is a patch:

In future, please try to minimize your log. Your log actually includes information of the session of keytocard before setting key attributes correctly.

I created D513: Support macOS build with SIP by using posix_spawn in tests/random, which is more conservative; It only affects build under macOS.

I created a different user on the same machine.
I logged with the addons enabled and disabled.

In T5159#139739, @werner wrote:

Put

extern char **environ;

after the the include directives.

Put

extern char **environ;

after the the include directives.

After applying @gniibe 's patch:

Changing this to priority low until I see a second report from a different user with a similar log.
This looks more like a broken Outlook setup on this users account then a problem where we can actually help.

No, which addons are active is a user property. So maybe you can try disabling all others but GpgOL, and then basically bisect which one it is that is conflicting.

The problem is that posix_spawn is not portable enough for libgcrypt. It is really time that we move the spawn functions from gnupg to gpgrt so that we can use them also in Libgcrypt.

BTW, I'm not sure if the claim in T5009#136688 is correct.

See also: https://dev.gnupg.org/T5009#136688

See my comment in: https://dev.gnupg.org/T5024#139701

After disabling SIP, now all checks pass without having the library symlinked to /usr/local/lib. So it might be T2056: libgcrypt: make check fails "random" test on OS X 10.11 with link error after all.

After doing:

Wouldn't the incompatibility cause all the users to have the same problem, rather than one not and all others to have the problem?
Attached is the file that you requested.

In general there always might be problems with incompatibilities of other addins installed on a system.

there was an issue that has been fixed in 3.1.14 which was creating problems / crashes when the home directory of a user had a unicode character in it. So maybe your one user had such a username?

Another issue that comes in to mind is that current ARM/ARM64 HW feature detection most likely wont work on MacOS. Thus HW accelerated AES&SHA&GHASH implementation wont be used.

IIUC, for the build of Homebrew, it is the issue of in: https://github.com/Homebrew/homebrew-core/commit/e7da1e2157b2e8373c3b39ea6398f51588ea537c

Please have a look at T5024: libtool problem for some platforms for 'make check' (program built with -no-install won't work without installation), if make check works after the installation of libgcrypt.

See T2056: libgcrypt: make check fails "random" test on OS X 10.11 with link error, if test with 'random' fails.

HAVE_COMPATIBLE_GCC_AMD64_PLATFORM_AS is never defined on ARM64 as it depends on "$mpi_cpu_arch" == "x86". Instead I think new check for GCC assembly ELF directives would be needed in configure.ac, similar to HAVE_GCC_ASM_CFI_DIRECTIVES check. Following check should work, but I have not yet tested it:

ARM64 has been only tested on platforms which support ELF.

I am quite aware of that each user has there own keys and configurations.
I added a third user to the computer, configured them the same as the first user, and was not able to sign or encrypt any emails.
When I clicked on the lock nothing happened.

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.