Back to WIP because I had to fix a regression.

Well, I tested this again. I created a new key and saved a copy. The I updated the expiration date to 2035 and sent the key to the LDAP server. Then I deleted the updated key locally and imported the old copy. Thus I have now:

https://invent.kde.org/pim/kleopatra/-/merge_requests/428

Yesterday I was able to reproduce it once. But despite more than a dozen more tries yesterday and this morning, I could not anymore replicate it. I tested on Unix and one oddity was that I forgot to kill the keyboxd for a clean new test and thus it could serve old keys despite that the pubring.db was already deleted (but the inode still open by keyboxd).

@timegrid I would not tag this ticket with LDAP, as it is not LDAP specific

State in Gpg4win-5.0.0-beta446 and vsd 3.3.4 is this:

After more testing, I agree, script integrity is not enforced, after all, although a warning about an unknown hash does show in the javascript console. After a first short dive into the manifest reference, I'm not sure we actually have a way to enforce a hash, though.

This is really weird behavior. It seems other secret keys in the keyring may also change to "undefined" validity when the certification is done with another key. And something about the key which is certified is important.
But it can also happen that it is enough to just import a secret key without certifying anything with it for it to be shown as "undefined" validity.

This task is obsolete as we do no longer use the Temp directory for encryption (I believe since vsd3.3.0/gpg4win 4.4.0). Instead the file is written directly to the target location with the ending ".part". It is renamed there after the encryption is completed.

If Kleopatra is started in standalone mode then it shuts down properly.

In T7972#209908, @svuorela wrote:

That sounds like a upgrading nightmare, so I really think we should avoid going down that path.

The aim of this ticket is to map the message in Kleo for the corresponding gpg case to the "Not found" error in gpgsm and thus show the other message instead.

With a Kleopatra built before the update of Qt/KF/gcc etc. (and which shuts down properly) I see the same three log messages.

In T7972#209893, @tfry wrote:

In T7972#209892, @m.eik wrote:

i wonder if it's possible to add hash sums of the javascipt file to the manifest and have them checked when the panel is opened? this would make it impossible for the proxy to serve compromised web clients.

Outlook actually does something similar (as I found out while trying to make some modifications to the .js code). It seems to calculate a hash, when the manifest is registered, and then refuses to load a mismatching file. You have to remove and re-register the plugin in this case.

In T7972#209893, @tfry wrote:

Outlook actually does something similar (as I found out while trying to make some modifications to the .js code). It seems to calculate a hash, when the manifest is registered, and then refuses to load a mismatching file. You have to remove and re-register the plugin in this case.

In T7972#209871, @m.eik wrote:

however, what would the web client do with the crypto hash after the exchange? simply show it?

In T7972#209892, @m.eik wrote:

i wonder if it's possible to add hash sums of the javascipt file to the manifest and have them checked when the panel is opened? this would make it impossible for the proxy to serve compromised web clients.

i wonder if it's possible to add hash sums of the javascipt file to the manifest and have them checked when the panel is opened? this would make it impossible for the proxy to serve compromised web clients.