I'm not sure if there is any way for the add-in to know which way it was installed.

As noted by @ametzler1 pinentry-qt has such a fallback. Of course, we can try to improve the heuristics pinentry-qt uses.

I tried but couldn't reproduce it any more. Therefore setting it to invalid.

Before making subtickets for each application: I wonder if it is not all Kleopatra anyway? Isn't the security approval dialog basically Kleopatra?

The equivalent for invalid S/MIME certificates are not-certified *PGP certificates.
(Valid/invalid are not ideal as technical terms as they have a broad general meaning, too. I hope my usage here is correct ;-) It is what I gathered from an explanation given by Werner.)

Note: The invalid revocation certificate: Bad signature - rejected line is also shown on vsd 3.3.4, gpg 2.2.53 @ win10 (but revocation works).

feedback of @mmontkowski needed

Invalid certs (as stated in the status column in Kleopatra) are mainly S/MIME certs (e.g. with missing root cert, CRL check failed, etc). I haven't seen invalid pgp certs yet (might be e.g. very old ones with missing self signature).

Invalid and expired are different cases.

Not a good idea. Because then the user will open it with the browser and the browser loads all kind of additional data including drive-by malware. If HTML *mail* is shown by a MUA no links should be followed to keep information and the fact that it was read confidential.

I think locate mode is mostly meant to be used to retrieve a single key

We talked about this in our developer meeting on Monday. I have never experienced the problem because I use the Qt version only on Windows and for my own use I use the Gtk version. In any case I think that Qt and fltk should fallback to curses to cover the case of using the Pinentry for a system startup on the console (e.g. the g13 case) with later switching to a GUI. And of course for those users who switch between GUI and console.

yes, we should only ask for an update of the manifest if its content was changed. the message should indicate that.

Issue 1) should be implemented as already described (on error -> dialog to retry with "always trust" flag)

@ebo and me talked about this and T6701: GpgOL: Use GPGME_ENCRYPT_ALWAYS_TRUST. We think, it's best to have a short meeting to discuss further changes.

Patch was merged upstream (KF 6.25): 332678d8a4f635d6938eb3e9ec03d845aa89697a