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?

Verified.

Thank you for your report.

Push the change: rG953dd67368ce: Use gpgrt_process_spawn API from libgpg-error.
Please test.

Thank you for your report. We are about to migrate to use the gpgrt_spawn_process API.
(In our development history, it was originally implemented and tested as gnupg_spawn_process API and moved to libgpg-error.)

ok, new try. As Ingo now clarified that that "nothing was imported" and "nothing was considered" is synonymous for him, then I misunderstood that comment. As far as I understand the "considered" that would mean that a tab would come up for import of unchanged keys, too.

ok, to make it clear how exactly to implement and test this, let me rephrase what my interpretation of your comment is:

Just a small addendum to what Andre wrote: Obviously, no tab should be shown if nothing was imported (i.e. numConsidered is 0).

Well, i can live with it. It would be an improvement.
I would prefer if no import tab was created if a key has not been updated and therefore nothing was actually imported. But I see that this would be more complicated to implement and I have no strong opinion on this anyway.

So Tobias fixed the technical reason why there was no import tab shown after the certify questions because I was too lazy (no I had no more time ;-) ) when I implemented this to carry the keylistcontroller around.

Thank you for the patch.

Using/setting a value of 2 would work for Kleopatra.

That is probably right for gpgme as used by kleopatra. However in gnupg we need to switch utf8 on and off.

Tested with version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta25)

Thank you for your report, good catch.
It's introduced by the commit: rC909daa700e4b: blake2: add AVX512 accelerated implementations
And the bug is there since then.

Fixed in rG01fa318be0f8: scd: Fix how scdaemon pipe server finishes.

Yes, the SO number changed. Before that you had run the test with an old version of the library or maybe the current one depending on your system. However, a changed SO number means that you have can have two versions of the library installed and they don't alias them with symlinks. We rarely update SO numbers but int he libassuan case we did it because technically we had a minor ABI change but GnuPG and Cie. are not affected; we did it anyway to be correct.

Strange - running sudo ldconfig prior to make check did indeed allow the tests to pass and the gnupg executable to build. I don't recall needing to do that until now; has something changed?

What you should is to to run

Asking a change of gpgme would need more time... So, I decided to change gpg-agent side.
gpg-agent part was done in: rGb3f1f2cd192b: agent: Handle SCD DEVINFO --watch command in a special way.

I don't know what the "speedo build method" is, so no. I've built this software many times before with the usual routine:

Did you used the speedo build method? Did you install libassuan first?

scdaemon part was done in: rG36d8cffc6cd2: scd: Finish DEVINFO --watch command on input close.