AFAICS, we need to implement a new Assuan flag and wipe the data passed to the callback after the callback returned.

Glad to hear. I've also now had time to manually apply the patches and have not seen any issues so far! Thank you! If anything does turn up later down the road I'll let you know.

No, no apologize needed. You did your best for the bug report, and it helped us a lot to identify the issue, and it certainly helped resulting the fixes. Moreover, your report kicked another fix of T5979 (thanks to the valgrind output).
Thank you.

I apologize, you seem to be right. Even though the package build log shows that all patches were applied, it seems there are some hunks missing in the generated sources.
I've attached my patches, but those are most likely correct. There seems to be an issue with my distribution's package manager. I will investigate this and report back afterwards. Maybe I'll just build it manually.

I do not claim I understand anything of this assembler syntax :)

For the second, I wonder if newer xlclang++ compiler works with 1.9.

Thank you for the bug report.

Pushed the change.

When compiling the package, I can see that all 4 are applied.

I think that it means that you only applied the last two patches.

Thanks for your confirmation.

Thanks again for your update.

Okay, confirmed: I was just wrong and the build failure was only ever with --disable-asm (i.e. the log in this bug is the only relevant one). Patch works.

Please disable all other Add-Ins as well as extra security tools running on that machine to see whether there is some interference with them.

But only with an option - in general showing expired keys is annoying. For revoked keys the situation is different in case of a compromise - but many users revoke old keys anyway and we don't make use of the revocation reason. If we would consider the latter the UI/Support would be more complicated than useful.

Thanks a lot for your cooperation.

TL;DR: can reproduce, needs fixing

Maybe we shouldn't exclude expired or revoked keys from the list so that people can still choose them. Of course, those keys wouldn't be accepted to be used for encryption, but it would help people to find out why the keys are not acceptable.

My email to gnupg-devel@gnupg.org was accepted and is visible in the archives https://lists.gnupg.org/pipermail/gnupg-devel/2022-May/035063.html
Cool

Thanks. Should be applied.

In T5950#158024, @werner wrote:

Please check the 2020 certificate by using the details dialog. Has it a valid encryption subkey?

Thank you for your fast reply. My apologies - I should have thought to do that (share log with asm enabled)! But now I'm confused. I think the failure was only ever with asm disabled. I will check with somebody else tomorrow just to make sure though.

Could you please give us the build log with no --disable-asm?

I put more fix for error handling of key algorithm attribute.
The change: rG53eddf9b9ea0: scd: Fail when no good algorithm attribute.

Thanks a lot for your cooperation.

Full build.log:

Contrary to your expectations, all gpg --card-status fail after yubikey insertion:

Please do experiment again and give us the whole log of scdaemon.log for:

• insert Yubikey initially
• run gpg --card-status (success is expected)
• remove Yubikey
• insert Yubikey second time
• run gpg --card-status (failure is expected)

In case you need any information, be sure to tell me. Maybe we can add some manual loggers to the patches, to confirm that everything is working as you imagine it to?

Umm... The problem is the last bogus octet from Yubikey. In the log, we see: