In T2291#139821, @lopter wrote:

if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?

Thank you for all the work! Does it mean that, if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?

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

For the record, Thomas from mailvelope confirmed by signed mail that this is the correct id.

I think that T5150 was also not fixed completely.

I found a bug which resulted "Not Found <SCD>" when "SCD KEYINFO" is used with "--data" or "--".
It is fixed in rG54b88ae46062: scd: Fix KEYINFO command with --data option..

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.

No plans to work on this.

Long since resolved.

For linking the MSI installer we already need a windows host and a windows sign host. The binaries inside that package we also sign usign the signhost / signkey which can be included in an optional / custom sign.mk during the build process. By default the path to the included sign.mk is gnupg-vsd/sign.mk in the src repo. But that can be changed of course.

Ah no, this is about the sending part, where we only encrypt to online validated keys, that is not mitigated at all. Disregard my last comment.

This is resolved with the preview feature in GpgOL-2.4.6 Gpg4win-3.1.12

Oh! Very Nice! Thanks for this. I've commited it with adding the uninstall parts.

I could find no issue with the error handling for verify errors.

I can't see how it occurs. "SCE KEYINFO" and "SCD READKEY" with keygrip both goes exactly same code path (the difference is only the "action" argument).

In T5163#139750, @werner wrote:

You better wipe ecc_d_padded or use xtrymalloc_secure.

Given that this is limited to macOS I have neither objections for 1.8 nor for master

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.

Go ahead (but w/o the /*if (keytime*)*/ line ;-)

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

For macOS, with SIP, some program like libgcrypt/tests/random fails, because the hack for DYLD_LIBRARY_PATH by libtool doesn't work for child process:
https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html

The following (probably not entirely correct) patch fixes the problem because it marks the PIV card key as pCARDKEY even though keytime is 0.

diff --git a/g10/keygen.c b/g10/keygen.c
index b510525e3..03c929c0b 100644
--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -4720,7 +4720,8 @@ quick_generate_keypair (ctrl_t ctrl, const char *uid, const char *algostr,

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.

@s7r Thanks for testing and letting us know!