gpgme.log (import of kyber team key with signing key):

gpgme.log (import of normal non team key kyber cert):

or maybe for the fist one "_ENC_ONLY"

Setting to resolved, as I think it should be

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.

Thanks Eva and Ingo. It seems 2.5.17 is not too far away.

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).

was tested already by timegrid

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

I assume, that testing the functionality is the only thing I can do here.

That was also fixed in gnupg 2.2.50 and thus vsd 3.3.3

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

Tested with gpg4win-5.0.0-beta479 @ win11

@tfry tested this, and it seems fine.

What I did wrong was that I did not include the global trustlist.txt (which is not read by default in Gpg4win) in the user trustlist.
This can be done by putting "include-default" at the beginning of the trustlist.txt in the users GNUPGHOME.

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.

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

Ebo was also able to reproduce it like this:

In Gpg4win-5.0.0-beta479 the dialog no longer exists. Problem solved ;-)

Gpg4win-5.0.0-beta479: works, no crash any more

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").

works, with Gpg4win-5.0.0-beta479 on Win11.
Now after hitting "save" a dialog is shown asking under which name the file shall be saved. Saving works with both options.

There is always a warning about bad signature.

I think we are all wrong here. We were tricked by the fact that regardless of the outcome of the signature verification the signed content is shown. That is surprising for a cleartext signature because that one can be viewed anyway. Thus I propose to not update the clipboard unless the signature checks out.

I originally uploaded a wrong copy of the file. Now fixed; the correct checksum is 8d830a2dd7e1e14ecbc47b8cdc61d393e9d3f62c

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.

Looks good to me on gpg4win-5.0.0-beta479 @ win11.
Both without and with DeviceInfoWatcher (via configuration as shown in https://dev.gnupg.org/T7045#186162 ):

• Removal of smart card -> smart card is removed in smart card view
• Insertion of smart card + gpg-card -> smart card is added in smart card view

Note that with gnupg 2.2 that file produces a BAD signature error due to internal changes in the armor parsing. You would need to spoof it a bit different with 2.2

I'm not sure, how to reproduce this. On gpg4win-5.0.0-beta479 @ win11 I quit Kleopatra with a smartcard inserted, the process exits with code 0, so it looks fine and I'm setting this to resolved.

Does not work on gpg4win-5.0.0-beta479 @ win11:

• Open encrypted mail and open attachments in outlook + reboot
  • All temporary files in "C:\Users\g10\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\ODXPL3A9" are still present after reboot (files with 002 ending additionally opened)
    
  • Temporary files are still present after opening and closing Kleopatra and Outlook
• Open encrypted attachment in kleopatra/mailviewer (via .eml file) + reboot
  • All temporary files in "C:\Users\g10\AppData\Local\Temp\kleopatra.XXXXXX" are still present after reboot (one folder per opened file)
    
  • Temporary files are still present after opening and closing Kleopatra
• Decrypt archive in kleopatra + reboot during the success dialog with the save button
  • Temporary folder "C:\Users\g10\AppData\Local\Temp\kleopatra.XXXXXX" with extracted tarball still present after reboot
  • Temporary files are still present after opening and closing Kleopatra

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

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

The imported cert was berta`s in this case.

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?

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?