Is a solution to this problem by an organization using pass for a log time with quite some users.

Thanks! Verified this builds on aarch64 correctly and generates the right flags on the output:

Hardened: /builddir/build/BUILDROOT/libgcrypt-1.11.0-3.el10.aarch64/usr/lib64/libgcrypt.so.20.5.0: Overall: PASS.

This excludes 32-bit ARM assembly from Aarch64 builds:

I cannot reproduce the duplication, there are probably errors in your log regarding that close / discard changes failed or something like that in this case as we leave the original message intact and only add the extracted mime parts as attachments and replace the body with the text mimepart. It would duplicate that when it would "reverrify" a mail that already went thorugh all this. But it is meant that while the mail exists in outlooks memory that GpgOL tracks that, too and so does not decrypt the same mail twice. What I can see is that multipart/signed without encryption is somehow parsed as S/MIME initially. This looks like some new behavior in Office 365 or recent versions of Outlook when the message class is changed to an S/MIME Message class. Which we do to get unmodified access to the MAPI structure. From the data objects looking at the mail in outlook spy:

In T7237#189558, @ikloecker wrote:

"Holder" doesn't exist for anything but OpenPGP cards and many people may not set it. Hence, I think it makes little sense to show this in a prominent location if it's empty for most users who don't juggle with loads of OpenPGP cards.

In T7226#189443, @jukivili wrote:

This patch should fix the issue:

0001-mpi-ec-inline-reduce-register-pressure-on-32-bit-ARM.patch4 KBDownload

"Holder" doesn't exist for anything but OpenPGP cards and many people may not set it. Hence, I think it makes little sense to show this in a prominent location if it's empty for most users who don't juggle with loads of OpenPGP cards.

As I could not reproduce the issue with different builds I realized that I was compiling and linking GpgOL for development using a very different version of winpthread.
When I switch to a consistent build and runtime library the crash no longer happens. I wonder if we can maybe statically link winpthread, too. But I think that is coming from Gpgme++ since GpgOL only uses windows threads.

Name, E-Mail, Status, Valid From, Valid Until, [Protocol], Key ID, [Fingerprint], [Certification Trust], [Origin], [Last Update], [Issuer], [Serial Number], [Tags], [Algorithm], [Keygrip]

A patch to make sure that certificates with ADSKs can be copied to cards: https://invent.kde.org/pim/kleopatra/-/merge_requests/265

to document the answer to my own question: The serial number is unique for the manufacturer, e.g. Yubico. But serial numbers of devices of different manufacturers might have the same serial numbers, although it is unlikely.

I added some comments to the commit. But

This works suprisingly well, without explicit invalidations i would not have expected that get icon is called automatically after the button or a subbutton is clicked. But I think that this then would require at least a test on the oldest supported version from us, too. Do we even have an old GpgOL test system?

Okay. Done in gpgme for gpgrt >= 1.51 (T7188).

Now even the error descriptions that are logged by background threads should have readable umlauts (see T7188).

Tested in our build environment and indeed, just this patch does not solve the issue for aarch64.

Screenshots of current state:

Markus this ticket I find important as it has much user visible impact. While VS-NfD secops say you "should" not use H TML mail, most users and basically all non - VS-NfD users use the default of outlook anyway and use HTML.

Mark for backport. In the past all columns were resized to fit their contents when a single column was made visible.

Mark for backport

Here's patch:

This patch should fix the issue:

Ok, so aarch64 assembly would need PAC and BTI support. As far as I have understood these, is that PAC instructions are not needed with current assembly as none of those is storing/loading LR register (all aarch64 assembly functions are leaf functions). So only BTI is needed and that is basically same modification as CET on x86.

This already shows with 9d909cb67e70fd792926ac1e2ab305b2cc96bc27 which initially added ec-inline.h. (Reproducing with old versions like this one requires cherry-picking 693ffa145378682229473b0e811a9cea7c4d307a since otherwise NEON support is disabled at configure time due to implicit functions.)