Interesting. I also wasn't able to reproduce this anymore, although I even created a new VM to make sure this is reproducible in a clean setup (and it was reproducible every time).
After restart of windows, it is reproducible again. This is the debugview output for an import without status update:

Looks good to me on gpg4win-5.0.0-beta479 @ win11.

I cannot reproduce this on Linux. Here I see that the file system watcher notices that trustdb.gpg was changed and triggers a keylisting.

Also: What happens if you cancel the ownership question and then change the owner trust of the key on the command line?

Please attach the log output of Kleopatra

Done

• progress/busy indicator shown (probably also read, but loading was too fast, so it skipped the text)

alt+m
Manage Smart Cards - Kleopatra  window
Loading smart cards...
tab control
OpenPGP - 0005 00009D58  tab  Alt+  O

Maybe it would be better to just not offer S/MIME certs with distrusted root cert?

Note: It does not seem to be possible to open a pdf from an URL, at least not via CLI okular.exe <URL> (it says Unknown protocol 'https').

I tried to get any error response but found those issues instead:

• T8017: Okular: Hang on signature with smime cert and distrusted root
• T8018: Okular: No error on signature with wrong passphrase

Fixed.

If all processes are killed before okular is opened, i get an error on "finish signing":

gpgsm.log (debug-all, whole process of signing)

Looks good to me on gpg4win-5.0.0-beta479 @ win11. The default path is now the same as the path of the opened file:

Regarding my comment T1825#191055 : The mane page has long been updated and gpgme support is also available. For the symmetric session key, see the feature request T8016

Looks good to me on gpg4win-5.0.0-beta479 @ win11:

• gpg --show-only-session-key --decrypt FILE shows only the session key
• gpg --add-recipients -r UID1 FILE adds recipients (tested with one or more uids)
• gpg --change-recipients -r UID FILE changes the recipients (tested with one or more uids)

Looks good to me on gpg4win-5.0.0-beta479 @ win11.
I can't reproduce ebo's nor pl13's issue.

Backported for VSD 3.4

The option

[Export]
AllowPublicKeyUpload=true

has been added. If this option is disabled (i.e. set to false) then Kleopatra only allows the upload of OpenPGP keys for which the user has the secret key.

Backported for VSD 3.4

Fixed everywhere where we export some certificate or public/secret (sub)key. Additionally, to space characters we also replace /, \, and : everywhere in the (proposed) file names now.

Fixed and backported for VSD 3.4

The problem was the keyserver configuration, which does not include a scheme (ldap:):

keyserver ldap.gnupg.test:389:uid=LordPrivySeal,ou=GnuPG Users,dc=gnupg,dc=test:pass:dc=gnupg,dc=test:

What does gpgsm -k --with-colons print for Werner's QES key? The usage / capabilities should contain s (for signing) and q (for qualified signing). If q is missing then something isn't set up correctly.

The issue is resolved in gpg4win-5.0.0-beta479 @ win11:

• no error for opening .eml files
• no error for starting kleopatra while running (also not started twice anymore)

Notes:

• "Save encrypted" is only "Save" in the UI.
• This is still reproducible in gpg4win-5.0.0-beta476 @ win11

I've created a global trustlist.txt at C:\ProgramData\GNU\etc\gnupg with an entry for the RootCA for Werners QES key with the qual keyword. (The local config would not work, according to the man page.)

Adding a new column to the layout is now remembered.
The with of the newly added column (Key-ID, all others are shown by default) is not set to the width of the content. But I think that is ok, one can increase the width manually and that is then remembered.

I am surprised that the solution with the separate tab was chosen… Looks like this:

works in Gpg4win-5.0.0-beta476

Ok, only 2 confirmations after the one above any more (for a standard key), they look like this:

Ok, my fault, I missed that in the beginning there was logging in the background which consumed gpg's error message.

If no logging is running in the background (that's something that often trips me…) on consecutive runs:

with Gpg4win-5.0.0-beta476

Yes, Kleopatra quits again with the beta from yesterday:

Fixed in gpg4win-5.0.0-beta476

Fixed by applying a patch to our version of MinGW. This affected all Qt programs build with Qt 6.10.

This has likely a similar cause as T1794

I have been able to reproduce this on linux with gnupg 2.5.14.
I had two users (named Alice and Bob in the example), each generating a key pair.
These are the steps:

• Both users have the "use-keyboxd" option in their common.conf (i could not reproduce the bug without this option)

Back to WIP because I had to fix a regression.

Well, I tested this again. I created a new key and saved a copy. The I updated the expiration date to 2035 and sent the key to the LDAP server. Then I deleted the updated key locally and imported the old copy. Thus I have now:

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

Yesterday I was able to reproduce it once. But despite more than a dozen more tries yesterday and this morning, I could not anymore replicate it. I tested on Unix and one oddity was that I forgot to kill the keyboxd for a clean new test and thus it could serve old keys despite that the pubring.db was already deleted (but the inode still open by keyboxd).

@timegrid I would not tag this ticket with LDAP, as it is not LDAP specific

State in Gpg4win-5.0.0-beta446 and vsd 3.3.4 is this:

This is really weird behavior. It seems other secret keys in the keyring may also change to "undefined" validity when the certification is done with another key. And something about the key which is certified is important.
But it can also happen that it is enough to just import a secret key without certifying anything with it for it to be shown as "undefined" validity.

The aim of this ticket is to map the message in Kleo for the corresponding gpg case to the "Not found" error in gpgsm and thus show the other message instead.

ok, yes, looks like this was not thought through. How about "Sign/Encrypt settings"?

for clarity: the current "password based encryption only" and "public key encryption only" are not about defaults, but completely disable the respective functionality. should they really be under "Sign/Encrypt defaults"?

I can't reproduce your problems. Can you get me the exact test files you used?

In T7774#209645, @ebo wrote:

isn't this done?