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.

The use of putc_unlocked has long been removed. So we should also remove the declaration. Normally this does not harm but in your case you may want to pass CFLAGS="-DHAVE_PUTC_UNLOCKED" to make or remove the above declaration.

The point here is to escape control characters so that we do not run into problems when reading the stuff. Escaping non-ascii (c >127) is not required and would put a lower limit on the number of (utf-8) characters we can print via the status lines.
Note also that we use almost everywhere ascii versions of the character checks. Thus I would not consider this a bug.

Verified the fix.

Maybe we can support this directly in gpgme's assuan API.

Did some experiment and I concluded (for now) that new command for gpg-agent would not be needed.
Instead, it might be better doing following in GPGME.

Pushed the change to master. Please test.
rCbb0895bbb7c6: m4: Fix acinclude.m4 for underscore detection in the symbol.

Thank you for the report.

Thanks for the detailed analysis; we will check to tomorrow why this was changed.

In T7175#187690, @jukivili wrote:

Hm, CFI directives should not be used on WIN32 target. This patch should solve the issue for now:

0001-src-hwf-x86-disable-inline-assembly-CFI-directivies-.patch984 BDownload

Here is a fix for the issue which preserves the removal of cut:

Using clang for Windows is not tested or suggested. Thus low priority.