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.

Addendum: I currently do not think we can do anything about this, except for documenting it.

I suppose you selected "Allow", then, and yes, that's enough to "fix" the problem. Chromium does remember the decision (unfortunately, it also remembers if you selected "Block", and some users are doubtlessly going to do so).

i didn't see any of this in chromium 141.0.7390.77, but i do after an upgrade to 143.0.7499.170. but only at the first start. when i closed chromium and launched it again, the logo appeared as desired (i did a successful pairing the first time).

when do you see this precisely?

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

Ebo was also able to reproduce it like this:

when do you see this precisely?

this was resolved

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.