Thanks for the feedback. The issues are the same as on win10:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Thu, Jun 26
After discussion with Ingo and others it seems that separate Kleo processes per GNUPGHOME would confuse more users than being helpful for power users. Considering the use case of gpgpass the conclusion was to add an option to Kleo which allows to start is as a certificate manager without doing the UniqueApplicaiton thing and also entirely quit after closing the window.
Regarding the "unsure" findings:
- invalid state in cert list tooltip (red on black)
Jun 25 2025
- Issues found
What about including the output of
On gpg4win-5.0.0-beta330 everything works fine again (both smime and openpgp regardless of expiration).
Jun 24 2025
I now imported all certs in testzertifikate_2023/ (smime and openpgp) and generated a new one (openpgp, default settings, expiration 2028) and still get no valid signing certs in okular
added gpgsm log:
Ingo mentioned some maybe related expiration year 2038+ ticket, but I only found one for kleo: https://dev.gnupg.org/T7069
Issue about no valid smime certs found on signing split into: https://dev.gnupg.org/T7697
This is more a technical ticket. There's not really something to test. Setting to Resolved/Done as discussed with ebo.
Note that the first screenshot shows still "Sign/Encrypt" as button text instead of "Finish", but I didn't notice that again after this
Most issues with icons in high contrast modes (of Windows 10) should have been fixed. Needs to be verified especially with the high contrast modes of Windows 11.
Setting to Testing.
Moving to QA. All changes should be in the latest beta.
Many issues have been fixed. Setting to Testing to check what I have missed.
Jun 23 2025
3 non-hang logs, all took ~20s to open the file (with 20s "Keine Rückmeldung" shown in Okular)
The problem with the invalid certificates seems to be unrelated. Isn't there already a ticket for Okular for certificates which expire after 2038?
If keyboxd sometimes takes 6 seconds, then I'm not surprised that stuff times out after 8 seconds occasionally. Or well. we need more numbers to determine that.
And in the first case, about 6 seconds are lost starting keyboxd:
2025-06-23 13:16:55 gpgsm[3252] DBG: chan_0x000000000000022c <- VERIFY 2025-06-23 13:16:57 gpgsm[3252] Kein aktiver keyboxd - `C:\\Program Files\\GnuPG\\bin\\keyboxd.exe' wird gestartet 2025-06-23 13:16:59 gpgsm[3252] Warte bis der Keyboxd bereit ist ... (8s) 2025-06-23 13:17:01 gpgsm[3252] DBG: chan_0x0000000000000260 <- # Home: C:\Users\g10\AppData\Roaming\gnupg 2025-06-23 13:17:01 gpgsm[3252] DBG: chan_0x0000000000000260 <- # Config: [none] 2025-06-23 13:17:01 gpgsm[3252] DBG: chan_0x0000000000000260 <- OK Keyboxd 2.5.6 at your service, process 4748
Here's the gpgsm debug log (debug x509,ipc,lookup):
The keylisting hangs ticket for Kleopatra: T6623
In T7658#202206, @svuorela wrote:@ikloecker is https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=f23cef6f66a44c5c1cc8717f74b658d14fde04e5 needed to be forward ported to split gpgmepp ?
@ikloecker is https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=f23cef6f66a44c5c1cc8717f74b658d14fde04e5 needed to be forward ported to split gpgmepp ?
It could be connected to those "keylists hangs" problems. On Kleopatra it took some time to refresh the key list. After that I can open the signed file again.
Well, now I also can reproduce the hanging on verification again (opening of an unsigned document is fine, of a signed document hangs).
Maybe the signing part above is important to trigger it - although it happened now in a clean state after a reboot, so it should not be caused by e.g. leftover processes.
I'm quite sure, that I used a fresh install on a new VM, but on another fresh one I can't reproduce the verification part anymore and the signature is shown as valid.
Jun 20 2025
Jun 18 2025
Jun 17 2025
Jun 16 2025
The only time I succeded in reproducing this was when I broke my gnupg setup and got a mix between gpg from one version and gpg-agent from another.
Jun 13 2025
Thanks! Maybe we should add a tooltip? "Default Appearance" does not have one and I do not find this self explanatory.
Jun 12 2025
In T7212#201964, @ebo wrote:Why are there 2 buttons for (probably) the same thing: "Default Appearance" and "Defaults"?
in 5.0-Beta-190
its not cleared any more in 5.0 Beta-190
If Kleopatra is already running then running
- kleopatra --help shows the help in a window
- kleopatra --help-all shows an error
- kleopatra --version, kleopatra --author, and kleopatra --license open the About window
Jun 11 2025
And mind that the wording "This certificate is revoked" is wrong in any case, only the user ID is revoked, not the public key.
Jun 10 2025
Jun 5 2025
I updated the version database. We now have entries for "gpg4win", "gpd", and "vsd"
Jun 2 2025
May 30 2025
Yes, for GPD and VSD there probably should be version numbers in swdb.lst if the update check should actually be active in those distributions. I think for VSD the update check is usually deactivated because a) it accesses the public internet which some customers don't want and b) the software is usually not installed by the users themselves so that the update check doesn't make much sense.
So, what shall we do with vanilla kleopatra, or GPD or VSD? It will be easy to record current versions number in swdb.lst
Tagging with Windows because the update check is a NOP except on Windows.
In T7656#201529, @ikloecker wrote:In T7656#201519, @TobiasFella wrote:Do I understand correctly that this bug is then automatically done/fixed?
It depends on how the version comparison works. We may have to change the code to extract the version number (e.g. 5.0.0) from the version string.
I forgot to mention that gpgrt has an API to compare version numbers in the same way gpgconf and all gnupg components do it; this should be somewhat similar to sort -V
BTW, if you append a beta string the thing works as well. Thus with an development version for 4.4.2 we would get a 'newer' state:
The version file is locally cached and updated from time to time unless that feature is disabled.
An update can be forced using
By the way, Kleopatra uses GpgME::SwdbResult::query() which I expect to do what you propose.