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.

In T7972#209908, @svuorela wrote:

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

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.

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?

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.

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?

In T7774#209645, @ebo wrote:

isn't this done?

Partial / WIP fix: branch work/tfry/refresh_draft_list

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()).

Apparently, the relevant option appears to have been renamed in outlook:

Related to T7972 and T7726 . Currently it would be unclear, whether we should fall back to some other available native client.

Part of the complexity could perhaps be offloaded to the proxy server, where it may be easier to perform cryptography.

isn't this done?

Proper key agreement would indeed be better. However, this needs to be implemented also in the browser without using a native messaging extensions. With the latter we could use gpg-pair-tool. But that introduced yet another complicated part; so better not and re-implement such a thing in Javascript.

i'd suggest to not send an actual shared ID for verification to protect against spoofing attacks. instead, the native client (NC) should generate a six digit number (or something similar) to verify in the web client (WC). if successfully verified, NC and WC should generate a shared secret via diffie-hellman key exchange. this can then be used for challenge-response verification during re-connecting the two.

• The proxy server may also limit the list of ids to offer to an unconnected web client to ids of native clients running on the same ip as the web client.

WebServer::processCommand, case Command::Register. When a web client connects, we send the mapping to both web client and native client. However, when a native client connects, we only send the mapping to the web client. We'd need both, here, too. However, we probably want to refactor both cases to use common code.

these articles on the graph API might be useful:

there have been changes affecting this:

That might be related to T2196 which has been hopefully fixed in 2.2.50 and also in the next 2.6. Closing this task.

That might be related to T2196 which has been hopefully fixed in 2.2.50 and also in the next 2.6. Closing this task.

We also discussed emails that can't be decrypted. They are due to implementation details just currently skipped. They will also be so in the future as an implementation detail.

Someone should test whether gpgol2 is able to reencrypt all subfolders of a given folder. The file reencrypt tool (current name "recipients" "hugh") does this already.