Right. And the MDC detects this and only if says okay you get a good decryption status back.

I may have misinterpreted what The GnuPG UI Server Protocol is. Instead, I will provide high-level functions to all of gpgme's underlying features

to make sure we talk about the same thing, it's about the status column:

The imported cert was berta`s in this case.

Interestingly, gpg also prints the warning about the missing trusted key signature when verifying a signature made with a revoked key that has a valid certification by a trusted key. This could be intentional (because the revocation invalidates all certifications), but it's still a bit surprising.

This warning shall only show up if a message was really modified and not in case of

a simple truncation.

In T8015#210735, @timegrid wrote:

In T8015#210727, @ikloecker wrote:

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

after gpg --lsign berta, the status value in kleopatra was updated automatically.

How does gpgsm react if you try to sign with the certificate?

Frankly, he OpenSSH support for Windows was experimental and I have never tested it. If it can be confirmed that this really works and is useful, it will be easy to add the opeion to gpgconf.

Oh, I just noticed that gpg doesn't say anything about the trust of the key if the key is expired. Compare this to the following output of gpg in case of a not-expired signing key without trusted certifications.

[GNUPG:] NEWSIG
gpg: Signature made Di 06 Jan 2026 16:35:20 CET
gpg:                using EDDSA key 98FB8E8F8E5F58FA653E17A6FC9B2EF2C62AC7BE
[GNUPG:] KEY_CONSIDERED 98FB8E8F8E5F58FA653E17A6FC9B2EF2C62AC7BE 0
[GNUPG:] SIG_ID mmuLNgiB0C7AfTaVYpNjZbcVQok 2026-01-06 1767713720
[GNUPG:] GOODSIG FC9B2EF2C62AC7BE t7790-expired
gpg: Good signature from "t7790-expired" [unknown]
[GNUPG:] VALIDSIG 98FB8E8F8E5F58FA653E17A6FC9B2EF2C62AC7BE 2026-01-06 1767713720 0 4 0 22 10 00 98FB8E8F8E5F58FA653E17A6FC9B2EF2C62AC7BE
[GNUPG:] TRUST_UNDEFINED 0 pgp
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
      98FB8E8F8E5F58FA653E17A6FC9B2EF2C62AC7BE

How I reproduced this:

• Create new test key
• Detached-sign some text with the new test key
• Change trust of test key to "unknown"
• Expire the test key (e.g. with gpg --quick-set-expire FPR seconds=1)

Other observations:

• after removing the smartcard reader again it's still not reproducible
• after win restart it's not always reproducible
• best chances to reproduce by killing all gpg related processes and deleting gnupghome and Gpg4Win folders first, then import

after attaching a smartcard reader with a smartcard, i can't reproduce this issue anymore

In T8015#210727, @ikloecker wrote:

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

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:

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.

Frankly, he OpenSSH support for Windows was experimental and I have never tested it. If it can be confirmed that this really works and is useful, it will be easy to add the opeion to gpgconf. Note that the gpgconf option feature handles only a subset of all options on purpose.

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: