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.

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.

In T7774#209645, @ebo wrote:

isn't this done?

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.

Thanks, I'll start here and see how it was done with JS for the browser: https://dev.gnupg.org/source/gpgme/browse/master/lang/js/

Except for GpgEX which I am currently working on.

Note that we have moved almost all bindings out of gpgme into separate repos. I suggest to develop such bindings externally. And you'll have to find external resources to learn how to create nodejs bindings for gpgme.

This might be obsolete after we have switched to Qt 6.10.

It's mostly obsolete. With T7874, GetThreadUILanguage is used instead of GetThreadLocale if no locale/language related environment variables are set. GetThreadUILanguage returns the configured display language.

Yes, this is obsolete with T7717: Location of qt-application config files. Closing as Wontfix because we use product-specific folders outside of GNUPGHOME.

Yes, this is obsolete. In the meantime KF6 uses GenericStateLocation instead of AppDataLocation everywhere so that there's nothing to upstream. And with T7717: Location of qt-application config files we set a product-specific value for GenericStateLocation below %LOCALAPPDATA%.

Backported for VSD 3.4

The tab order is horrible, but with the right combination of Tab and Shift+Tab it is possible to set custom keyboard shortcuts and the remove them again.

Partial / WIP fix: branch work/tfry/refresh_draft_list

Fixed.

There are actually two separate causes for this:

• For newly created drafts, the native client fails to keep track of their existence. It will thus only "find" them, when it is re-started.
• Beyond this, the only place where drafts are synced is the "info-fetched" command. This is sent in response to the "info" command, and that only gets sent when changing to a different email, or reconnection. Further, only reduced info (not drafts) is sent back to the web client, in case the message was already cached in the native client (WebsocketClient::info()).

This is still the case in Gpg4win-5.0.0-beta413