I do not have Aarch64 machine at hand so what I did was building the package with changes on the build system with previous patches and checking the correct flag are in place (previously in RHEL10, but now in Fedora):

Well, my hope for this was some kind of Format where we keep the keys + the signature together with encrypted files. Because I think it is an extremely common usecase to decrypt a file, modify it and then to reencrypt it to the recipients that it was encrypted to before and I think it would be a good usability improvement if after decryption, when a file is then encrypted again Kleopatra would have the recipient dialog prefilled with the original recipients. T6564: Kleopatra: Re-encrypt an encrypted folder to the original recpients And for Gpgpass this could be used in exactly the same manner just with a diffrent UI and focused on folders with multiple files.

Do you have any way to test PAC/BTI on actual HW that support these extensions?

I am not sure I like every aspect of passtore.sh (e.g. the YAML configuration files and yet another group concept where we probably could reuse Kleopatra groups), but it's good to know that there is already a solution for this issue :)

Alright. Done for master; backport will come soon.

I understand the problem now. The difference between my test yesterday and today was that I had disabled S/MIME support in my GpgOL. Since T7243: GpgOL: multipart/signed OpenPGP SMTP transfered mails are displayed as S/MIME is an issue that makes GpgOL think that it is looking at an S/MIME mail but S/MIME is disabled, it tries to write back the mail to the server in a way so that Outlooks internal S/MIME support can parse it on the next run. In the log you see:

Today this was reproducible for me, too. Not sure what the difference is yet to yesterday I could see in my logs that this time the mails were never completely unloaded so that might be a reason. But we cannot rely on that. So reopening mails must work of course even if the mail stays open. (Good to simulate by keeping outlook spy active on the mail when loading and unloading).

To clarify what I mean by the missing VarFileInfo block. Currently the GnuPG binaries have versioninfo.rc files but only the version number is displayed for dlls as their pattern did not have the VerFileInfo block: The libassuan-0.dll displayed in this screenshot is from the 2.2.43 package and the assuan-9.dll is self compiled but including the patch below that. I would like to commit such a patch to all libraries that require it if that is okay with you.

Using signed files would have been my suggestion, too. For me I would say that "allowed to sign" depends on the ownertrust of the signature certificate. If the ownertrust of the certificate is Ultimate then you can accept the recipient list. Ultimate ownertrust is given for your own keys or for the ones marked with trusted-key in the GnuPG configuration.

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.