So why are there different grades of failure? Why is "invalid packet" a less scary error message than "WARNING: message was not integrity protected" when both are equally bad things?

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.

It looks similar if the key is in a WKD: First search fails without error, only "no certificates found" is shown. Clicking "Search" again results then in the expected key being found and shown.

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

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

completed: draft all gpg key function names

I decided to prioritize developer experience and provide simplified, high-level functional abstractions instead of maintaining 1:1 parity with the underlying gpgme library functions. See example in T8021

Traditionally we have considered expired and revoked more or less similar. The idea is that an expired key might have been compromised but the owner did not found a way to revoke it. We may want to change this policy because some users don't care too much about expired keys (cf. T7990) .

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

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.