Backported for VSD 3.3

FWIW, I received that mail but I hope that this bug is at least fixed with today's fix for T7213. Thus not re-opening.

This patch has a new fix for T5793 which is now only used where needed.

I don't think that we can do much manual testing here because we have all test cases anyway in the regression test suite and our local non-public regression tests (which has the p12 files we are not allowed to publish)

Setting this to testing. Could be tested as described in https://dev.gnupg.org/T7188#188093 by verifying that the logged debug messages also use correct encoding.

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):

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

Alright. Done for master; backport will come soon.

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:

In T7226#189443, @jukivili wrote:

This patch should fix the issue:

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

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

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

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

Sounds like a good idea.

@werner Would it be okay to call gettext_use_utf8 (3) in gpgme's do_subsystem_inits where we currently call gettext_use_utf8 (1)? See https://dev.gnupg.org/source/gpgme/browse/master/src/version.c$77

Alright: Call gettext_use_utf8 (3) to set the current thread to utf8 and init all new threads to utf8 as well. This function with that value (actually bit 1 is relevant) can be used several times but it will never switch back the initialization to utf8. However, switching back and force to utf8 per threads is still possible.

Yes, the function to load the user-configured language on application start is very well hidden in kxmlgui. :-)

I mean the system configuration of Windows is just strange and messy. I am only noticing this now more because for my latest Test VMs I used VIrtual Box unattended installation, which installs the system according to the Hosts locale and then you can change the language for your user in Windows. And I ended up with this setting here where the preferred languages differ from the Windows UI language. And we are not alone in a confusion, on this system also Paint is in english, and the Microsoft Calculator, but not Powershell or CMD 🙄 But as GetUserPreferredUILanguages should return (and does according to my tests) the display langue chosen in the drop down as Language[0] and the others with lower priority I think the correct behavior here is to be in German.

In T3733#189355, @ikloecker wrote:

Don't change the existing KDE behavior for loading the correct Qt translations which is the same as gettext's behavior. It took quite some time to get it right on Windows for KDE.

In the past I have also seen quite often that the Qt Translations with standard actions like OK and Cancel were translated differently then KDE Strings. So there is also some difference with that on Windows.

KConfig uses the default locale instead of the system locale by default it seems:
https://invent.kde.org/frameworks/kconfig/-/blob/master/src/core/kconfig.cpp?ref_type=heads#L118
This should probably also use a copy of ki18n's getSystemLocale() instead. Or we set Qt's default locale to this value to get KConfig to use it.

Don't change the existing KDE behavior for loading the correct Qt translations which is the same as gettext's behavior. It took quite some time to get it right on Windows for KDE. The important bits for making the language configured by the user work are in
https://invent.kde.org/frameworks/kxmlgui/-/blob/master/src/kswitchlanguagedialog_p.cpp?ref_type=heads#L64
where the user-configured languages are prepended to LANGUAGE and in
https://invent.kde.org/frameworks/ki18n/-/blob/master/src/i18n/main.cpp?ref_type=heads#L65
where we make sure that we load the correct Qt translations also on non-Linux systems (where Qt doesn't respect LANGUAGE).

With debug output I have confirmed that KConfig uses the defaultLocale at this point to read the VS-NfD name. So one issue here is that KConfig needs to use the Language configured for translations when reading out the config from which we take the VS-NfD name.

as this is a regression, I would like to have a fix in the upcoming release

The garbled data might be due to a bug in dumpasn1 (version 2021-02-12).

I notices this again, even though my display language is german and Kleopatra is german the GnuPG system is using english (gpg-error --locale says en_IE). en_IE was set by virtualbox during windows installation. No environment variables are set related to language.

Recent changes fixed the issue for the x86_64 builds, but I see similar symptoms in the aarch64 build now. Annocheck reports the following failures:

Hardened: /usr/lib64/libgcrypt.so.20.5.0: FAIL: dynamic-tags test because the BTI_PLT flag is missing from the dynamic tags 
Hardened: /usr/lib64/libgcrypt.so.20.5.0: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-dynamic-tags.html
Hardened: /usr/lib64/libgcrypt.so.20.5.0: FAIL: property-note test because properly formatted .note.gnu.property not found (it is needed for branch protection support) 
Hardened: /usr/lib64/libgcrypt.so.20.5.0: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-property-note.html

I do not have aarch64 machine at hand now to investigate this further, but this sounds like orthogonal functionality to the CET on Intel.

Yes, we can phase it out in master which is what Nico is talking about and which uses Qt 6/KF6. Nobody is going to remove KIconLoader from KF5.

Btw. Here is a nice backtrace, which I think is similar to the crash part of this Task:

I think the crash in the end is the same we have in T6688: Kleopatra GPGME: Reported assert on exit where quitting kleopatra with running jobs tries to cancel all open contexts and then crashes where the assert would be triggered in debug builds. In T6688 we just hid this issue again by not keeping the deviceinfowatcher running.

Fixing this is important for getting the next release out.

Is the QIcon API available in QT5 ? If not we can't phase that out.

Thank you. With this patch the IBT flags are present on the shared object and CF protection test passes.

"rijndael-vaes-avx2-i386.S" should not be build for x86-64 but until now that has not had any affect as #ifdefs in that source file result empty object file on x86-64.

Thank you for having a look into this!

Not for a broken compiler but for several CC versions which consumed lots of memory for unrulling stuff. iirc, this was not only gcc.

Here's patches for adding CET support to x86-64 and i386 assembly.

OpenBSD carries libgcrypt patch for CET which adds endbr64 instruction to CFI_STARTPROC() macro in "asm-common-amd64.h". We could do the same and also add endbr32 to i386 too. That would be easiest way to add required endbr instructions. OpenBSD also has patch for arm64 to add similar BTI instructions to aarch64 variant of CFI_STARTPROC.

There is -O flag munging for "tiger.o" in "cipher/Makefile.am", an old workaround for broken compiler I think. IMHO tiger.o case can and should be removed.

OpenBSD carries libgcrypt patch for CET which adds endbr64 instruction to CFI_STARTPROC() macro in "asm-common-amd64.h". We could do the same and also add endbr32 to i386 too. That would be easiest way to add required endbr instructions. OpenBSD also has patch for arm64 to add similar BTI instructions to aarch64 variant of CFI_STARTPROC.

https://invent.kde.org/pim/kleopatra/-/merge_requests/255 fixes some low-hanging bugs to make the configuration behave more as expected

The only change i remember and can find regarding that, is, that for the initial keylisting we disabled the check using the context flag T6261: Kleopatra / QGPGME: Use --no-auto-check-trustdb for initial keylisting since we suspected that this had something to do with reports that the initial keylisting either locked up or was very slow. At the least the goal was that by no auto check trustdb on the initial keylisting it would make it behave more consistently from start to start. But I am pretty sure that you told at least me, that Kleopatra should not try to explicitly do trustdb checks and try to manage that since gnupg takes care of this internally.

I'd be in favor of keeping the UI and just fixing the most significant bugs it has.

Just to clarify: I didn't say that we should remove the coloring/font style of certificates. I just said that I vote for removing the UI for changing the colors and font style.

Mh, no, on the other hand the style is useful in the "All certificates view" to make distinctions based on multiple parameters. "Like trusted S/MIME root certificate" and it is useful to see that right away instead of using the filters. So my vote would be to clean it up, but keep it in general.

Hard to decide as we have no data how much it is used. :-/ But I tend to agree here. We should not loose sight of the fact that Kleopatra should be more of a diagnostic tool and provide all the information a user might need to solve their issues with signing, verification, encryption and decryption. Kleopatra is not something a user uses so often that they play around with appearance or so like they maybe would in a MUA. Certificate management is just an unwelcome side effect required for crypto. But users do not want to do certificate management for its own sake.

I vote for removing the UI for configuring the appearance of the certificate categories completely from Kleopatra. This would solve all usability problems in an instant. People who want to go crazy with colors can edit the rc file.

You could use colors, fonts, icons to mark any certificate you want instead of having to use tags and filter by them. You could even put their company logo on certificates of your communication partners.

In T7212#188683, @ebo wrote:

We might also consider going all out and allowing a configurable appearance on a per certificate level. Then this feature would see an increase in use for sure. But it should work without issues, in that case, as then people will notice them…

From the support angle, the worst of these issues is that the default will not be restored for VS-NfD. But then: nobody has inquired about that yet…

The high-contrast modes disable all colors, but for normal dark modes we might have a problem with some of the predefined colors.

Uhm this is a task I have with High priority. I do not know what to do here or what it is really about. -> Invalid.

Yes, this is all something that is ugly. The VS-NfD colorization was done by justus winter back then since I fell sick and it was one of his first and only tasks in Kleopatra. So it is normal I think if that is implemented differently then other things. And in general the whole appearence configuration is I think rarely used. To me it always felt like a "We add it because we can." feature. But also with this mix of filters defined in a preinstalled libkleopatrarc and additionally hardcoded filters it is all strange.
Well colors and so on should be changeable for accessibility of course.

As for renaming "Change Reset Code" to "Set Reset Code", what about "Change PIN" and "Change Admin PIN"? Should they also be renamed? If not, why not? Is there no default reset code? Is there a way to find out whether the reset code has already been set (in which case "change" would be more appropriate than "set")?

Fixed in: rG1e6b96577f68: gpg: Fix agent_probe_any_secret_key.

https://invent.kde.org/pim/kleopatra/-/merge_requests/242

• Don't show the tab if the certificate list was empty before the import
• Show tab when any keys were considered, not only when any keys were imported

are there any news about the problem with the control file?