I think this has been resolved in Gpg4win 5.

The suffixes _ENCRYPT_SIGN and _ENCRYPT are used to differentiate the two export results.

If only the secret encryption subkey is exported and there is a signing subkey then, additionally, to the secret subkey export a public export is added to the created file, i.e. in the created file there's a PUBLIC KEY BLOCK and a PRIVATE KEY BLOCK. (With the next version of gpgme the public key block only contains the primary key and the signing subkey. Currently, it's a full public key export of the team key.)

In T7455#211465, @timegrid wrote:

Notes:

• The "Encrypt..." and "Sign..." operations might not be needed anymore now, that "Sign/Encrypt ..." is available?

I've changed this now to "GnuPG VS-Desktop" (and "GnuPG Desktop").

We set the following organization names for the different products:

• Gpg4win: Gpg4win
• GnuPG Desktop: GnuPG Desktop
• GnuPG VS-Desktop: GnuPG VS-Desktop

i.e. the registry path for Kleopatra settings will be for example
SOFTWARE\Gpg4win\Kleopatra\<config group>\<config entry>

@werner: gpg fails to batch import secret Kyber keys:

$ GNUPGHOME=/home/ingo/dev/g10/.gnupghomes/empty gpg --batch --import --verbose ~/dev/g10/testdata/exported/Kyber768_0xDD89C34EF2B69576_SECRET.asc 
gpg: WARNING: unsafe permissions on homedir '/home/ingo/dev/g10/.gnupghomes/empty'
gpg: enabled compatibility flags:
gpg: sec  brainpoolP256r1/DD89C34EF2B69576 2024-11-14  Kyber768 <kyber768@example.net>
gpg: using pgp trust model
gpg: key DD89C34EF2B69576: public key "Kyber768 <kyber768@example.net>" imported
gpg: key DD89C34EF2B69576/DD89C34EF2B69576: secret key imported
gpg: key DD89C34EF2B69576/D07DD3BF9F1AAF4F: error sending to agent: IPC parameter error
gpg: error reading '/home/ingo/dev/g10/testdata/exported/Kyber768_0xDD89C34EF2B69576_SECRET.asc': IPC parameter error
gpg: import from '/home/ingo/dev/g10/testdata/exported/Kyber768_0xDD89C34EF2B69576_SECRET.asc' failed: IPC parameter error
gpg: Total number processed: 0
gpg:               imported: 1
gpg:       secret keys read: 1

Backported for VSD 3.4

Done. I've used the following script to create clear-signed test messages with good/bad signature signed with certificates with different validity and status (expired, revoked).

All sub tickets are done.

This is ready for testing and available in 5.0.0-betaX since about a year.

Should be ready for testing. This is available in 5.0.0-beta479.

This has finally been merged.

In the meantime we don't show the imported certificates anymore in the main window as tabs but in a separate window, i.e. import tabs are no longer an issue. Please retest.

I'm pretty sure that this is done. For gpd5 the changes have been merged upstream and kconfig reads the config keys in the desired order.

I can reproduce this on the command line:

C:\Users\g10code>"c:\Program Files\GnuPG\bin\gpgsm.exe" --export --armor 579BAF3DF16AD462457BCC0897ADBC143D76EA7B 5A2B80F98F518D50891B1F0C7C6131AD107F9938 DB625D2BBBB5A3FD985C0233249B03090E85D402
Issuer ...: /CN=CA IVBB Deutsche Telekom AG 20/OU=Bund/O=PKI-1-Verwaltung/C=DE
Serial ...: 02195D190EBE34
Subject ..: /CN=iOS Test-Smartcard iostest01.sc/OU=BSI/O=Bund/C=DE/SerialNumber=2
    aka ..: iostest01.sc@bsi.bund.de
Keygrip ..: 527CE32FD0552D18479442EF90DD5E434C036329

I can reproduce the issue only (!!!) with keyboxd (on Windows).

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.