The following logs indicate that the file system watcher detects a change of those files and that triggers an update of the keylist and the smart card view. Please check whether those files are indeed rewritten on every iteration.

[9508] org.kde.pim.libkleo: "C:/Users/Andre Heinecke/AppData/Roaming/gnupg/private-keys-v1.d/83DAC0502E57C04D7EEC05847D79429C92EEEC01.key"
[9508] org.kde.pim.libkleo: "C:/Users/Andre Heinecke/AppData/Roaming/gnupg/private-keys-v1.d/FE2E7817335F19F3338EC62086B4D666F6292101.key"
[9508] org.kde.pim.libkleo: "C:/Users/Andre Heinecke/AppData/Roaming/gnupg/private-keys-v1.d/961BF16F4EE095BC36EC5F6339F1BA10A561C0C5.key"
[9508] org.kde.pim.libkleo: "C:/Users/Andre Heinecke/AppData/Roaming/gnupg/private-keys-v1.d/3BE5196862C68A4C7B4C850D552070A0CE772827.key"

Yes, we can probably wait for Qt 6. It may anyway need to be fixed directly in Qt.

Does Qt log failed connections?

Regarding the visibility: If you certify after opening or closing the advanced options, the visibility is remembered, otherwise not.

Eva said this worked with older installers. Otherwise, she wouldn't have reported T6566 as-is. What changed is that we now use QuickJob/QGpgMEQuickJob instead of DefaultKeyGenerationJob (the one defined in QGpgME).

This may not be reproducible on Windows for the same reasons as T6813.

The only possible explanation I can see is that the signal-slot connections (using function pointers and lambdas) don't work because the progress dialog should be hidden when the job emits done() (which works on Linux with test_keyresolver).

I'm not seeing this on Linux with test_keyresolver as mentioned in T6566. Even after allowing test_keyresolver to be run in sign-only mode as seen in the screenshot.

Fixed with the above two commits.

Hopefully fixed for good.

What about the second part of https://dev.gnupg.org/T6742#176528? Should I make a separate a11y ticket for that with low prio?

Some observations on Linux:

• If I cancel sign&encrypt archive while the encryption is still running then Kleopatra removes the .part file. I didn't see a running gpgtar or gpg process after I canceled.
• If I cancel sign&encrypt archive by canceling the pinentry (asking for the password of the signing key) then the gpgtar and gpg processes keep running for a short time and Kleopatra still shows the progress. Eventually Kleopatra shows an error (General Error) instead of simply closing the window (-> T6575: gpgtar: General Error is emitted instead of more specific error codes). In this case Kleopatra didn't (have to) remove the .part file because it was already gone.

The same happens when the pinentry is canceled, i.e. General Error is reported although in this case the dialog should simply be closed (because the user canceled the operation).

Exactly. If possible. Kleopatra tries, but it's not able to remove the file. Because some process in the background keeps it open.

I like the explicit check boxes in the file encryption dialog more than this "hidden" combo box entry. (BTW, the file encryption dialog says "sign as" and "prove authenticity (sign)" but in this case there's little potential to confuse "sign" with email signatures. The wording should probably still be unified.)

Sure. But in both cases they get back an error code and then, back in safe Kleopatra territory, they convert this error code into a string. I don't see how this error code to string conversion should have anything to do with the way the commands triggered the operation. Both conversions should happen in the main thread, so that the state of libgpg-error should be identical. The logging will show if in the still failing case libgpg-error is not switched to UTF-8 for localized texts.

The same happens with a very recent 2.4:

$ gpgv --version
gpgv (GnuPG) 2.4.4-beta56
libgcrypt 1.11.0
Copyright (C) 2023 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I need the S/MIME group if I shall look into this. Are you sure that all S/MIME keys in the group can be used for encryption? Groups containing sign-only keys (OpenPGP or S/MIME doesn't matter) are never offered for encryption. That's why we wrote T6722: Kleopatra: Forbid adding non-encryption keys to groups.

We are now generating a key with whatever defaults gpg uses.

Setting back to Testing to get some more debug logs with a build that includes the latest commits.

Thanks for the update.

See https://dev.gnupg.org/T6685#174802

See T6736#177624 for the possible cause of the off-by-one day problem.

The observed behavior is exactly what was requested in T6743

Update: "can encrypt" should determine if an encryption subkey exists for a key in the keyring associated with the given email address. If that key is expired, it should be displayed appropriately marked and the encryption button greyed out.

I tried to reproduce this but I didn't succeed. I used "Create New OpenPGP Cert" for my attempts.

In general, the changes look good.

Fixed.

Whether the confirmation dialogs are shown is configurable in the config file (just like any other "Don't show again" option, e.g. the question asked when you quit Kleopatra). Simply remove the corresponding entries in the [Notification Messages] section to make Kleopatra show the confirmation dialogs again.

The same is true for trying to unblock the card with the PUK. Again I have to enter 3 PINs in 3 windows before being informed that the entry in the first window was wrong. Additionally, the text in window 1 is borked

If you try "Change PIN" next, you will be asked for the PIN and 2x for the New PIN in altogether 3 pinentry windows before being informed that the PIN is blocked.

After the 3rd entry of the wrong PIN, this is exactly the same.
Here I would wish for not only the popup "wrong PIN" but additionally this popup should declare "PIN blocked".

This is inconsistent, as usually a separate window would pop up for pinentry errors.

Fixed for Sign/Encrypt Files/Folders and Sign/Encrypt notepad.

Fixed for Sign/Encrypt Files/Folders and Sign/Encrypt notepad.

I would rather like to see the checksum stuff be ripped out of Kleopatra into a simple standalone app. It's complete overkill to start the Kleopatra battleship if the user just wants to calculate or verify a checksum of a downloaded file. The UI of the checksum tool in Kleopatra is anyway still not accessible (T6099: Kleopatra: Make checksum verification accessible). How about we redesign the UI from scratch with accessibility in mind from the start?

The changes affect:

• State of "Clipboard -> OpenPGP Sign" action in tray icon context menu
• Selection of signing key in "OpenPGP Sign Clipboard" dialog
• Selection of encryption key in "Sign/Encrypt" via dialog
• Selection of recipients in "Encrypt Clipboard" dialog
• Usage information in tool tips for certificates in main certificate list

Eva tested a few expiration dates for new keys: For 2038-01-18 the date is correct. For 2038-01-20 and 2106-02-05 the expiration date of the new key is 2038-01-21 and 2106-02-06 respectively. Kleopatra passes the date as ISO date.

Should work now. Please test if the auto-detection works. (Tumbleweed builds Qt 6 without "reduce-relocations", so that I cannot check it on my system.)

Small correction: On my/our system (Tumbleweed) the test without -fPIC always succeeded, so that -fPIC was never added. That's why I removed this useless test which, as it turns out, wasn't useless on your distro (@dfaure-kdab Which distro are you using?).

We now use a temporary .part files when creating the archive. On success, they are renamed. Otherwise, they are removed (if possible).

Done. Will be tested with the parent issue T6584.