Okay. Confirmed and understood. The problem is that file system watcher doesn't watch the trustdb.gpg file because the file did not yet exist when the watcher was initialized. And during the import we disable the file system watcher so that it doesn't notice the creation of the file and therefore doesn't start watching it.

I have verified (by looking at QTextEdit's code) that, on paste, QTextEdit splits the text for the internal representation into lines and discards any CR and LF characters.

It turns out that Kleopatra's notepad converts the CR characters of the spoofed file to LF characters when pasting the text so that Kleopatra doesn't really verify the content of the spoofed file but different content. And this results in a bad signature. The confusing bit is that Kleopatra also says "Successfully verified the notepad" and that it shows the claimed-to-be-signed text although the signature is bad which could lead an inattentive user to the assumption that the signature of the displayed text was actually good (because "Successfully verified").

On Linux, Kleopatra (master) with GnuPG 2.5 (master) shows a BAD signature. It shows the same output as running gpg --verify --output bla.txt in Konsole and pasting the file content (by maybe the copy paste changes some control characters). If I run gpg --verify --output bla.txt <payload.spoofed.asc then bla.txt also contains the same data.

Verification results for a few more cases (to help with the correct implementation):

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.

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.

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)

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

Fixed.

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

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.

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

Back to WIP because I had to fix a regression.

If Kleopatra is started in standalone mode then it shuts down properly.

With a Kleopatra built before the update of Qt/KF/gcc etc. (and which shuts down properly) I see the same three log messages.

Note that we have moved almost all bindings out of gpgme into separate repos. I suggest to develop such bindings externally. And you'll have to find external resources to learn how to create nodejs bindings for gpgme.

This might be obsolete after we have switched to Qt 6.10.

It's mostly obsolete. With T7874, GetThreadUILanguage is used instead of GetThreadLocale if no locale/language related environment variables are set. GetThreadUILanguage returns the configured display language.

Yes, this is obsolete with T7717: Location of qt-application config files. Closing as Wontfix because we use product-specific folders outside of GNUPGHOME.

Yes, this is obsolete. In the meantime KF6 uses GenericStateLocation instead of AppDataLocation everywhere so that there's nothing to upstream. And with T7717: Location of qt-application config files we set a product-specific value for GenericStateLocation below %LOCALAPPDATA%.

Backported for VSD 3.4

The tab order is horrible, but with the right combination of Tab and Shift+Tab it is possible to set custom keyboard shortcuts and the remove them again.

Fixed.