Today
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:
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:
So the message is "Update Failed" for keyserver and "not found" for WKD.
In light of that the ticket is this old, I'll leave it at that instead of discussing further improvements beyond this single phrase.
These would have to go in a new ticket.
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.
Yesterday
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.
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.
Tue, Dec 16
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.
securing the proxy is probably more difficult than paring NC and WC securely... for instance, the proxy is serving the very javascript file that literally is the WC. it can therefore introduce all kinds of nasty stuff on that side without anyone noticing. on the WC side, i wouldn't worry so much about the encrypted mails, as the NC is the only one that could decrypt them. but couldn't a compromised WC request access to all unencrypted mails as well and send them to the proxy for whatever purpose? or become a crypto trojan?
ok, yes, looks like this was not thought through. How about "Sign/Encrypt settings"?
Other than stealing metadata and preventing communication and maybe sending evil emails on your behalf, I'm unsure what a hostile proxy can do. I'm not sure we should assume it is hostile.
for clarity: the current "password based encryption only" and "public key encryption only" are not about defaults, but completely disable the respective functionality. should they really be under "Sign/Encrypt defaults"?
I can't reproduce your problems. Can you get me the exact test files you used?
that's an interesting idea. at least if we can assume the proxy server isn't already compromised (the critical part is during pairing/key exchange to prevent mitm attacks, right?). however, what would the web client do with the crypto hash after the exchange? simply show it? wouldn't we have to add some signature or (symmetric) encryption to sent messages in order to verify content is exchanged between paired partners? i don't see yet how this would work without some crypto capability in the web client. or am i missing something?
This relates to T7917: Check for revocation of the ADSK's original subkey
The expected behavior is that only "Ted" (the key from where the ADSK originates) is listed, regardless of ADSKs, on every listing.
Because for regular keys there can only ever be one, "gpg -k" shows always only one key.
Subkeys which are ADSKs shall therefore never be listed with this command.
Tested with Gpg4win-5.0.0-beta446, identically to the procedure from the description:
I can see AutomationIds now, but some are missing, e.g.:
- toolbar buttons (looks like buttons in general)
- tab items
- table header / tree items
ok, then this ticket will be for improvement of the usability.