Connection with xpra-html5 4.1.2 using AES and password fails

[olifre]

Starting a server on Debian 10 with (I'll upgrade the syntax at a later point):

/usr/bin/xpra start --html=on --bind-tcp=0.0.0.0:58745 --start="xterm -fa Monospace" --tcp-auth=file:filename=one --tcp-encryption=AES --tcp-encryption-keyfile=two --clipboard-direction=both --no-mdns --no-bell --no-speaker --no-printing --no-microphone --no-notifications --no-systemd-run --sharing --no-daemon

and then connecting to that with the HTML5 client via:

http://localhost:58745/index.html?encryption=AES&key=LxFbWx13KicDSxHR&username=olifre&password=PGzabTnSEE2jd5Pn

(with the file one containing the password without trailing newline, and two containing the key without trailing newline) stops loading at:
WebSocket connection established

Logging on the server side stops at:

2021-04-21 17:13:31,308  sending challenge for username 'olifre' using hmac+sha512 digest

I use Firefox 88.0 to connect, there are no errors in the browser console. The last lines are shown in this screenshot:

I can confirm that downgrading only the xpra-html5 package to xpra-html5=4.0.6-r28351-1 fixes the issue.

[totaam]

Should be "fixed" by the commit above: we just don't use rencode when AES is enabled. (hopefully, TijZwa can fix this properly instead in #18)

@olifre Can you try one of the latest beta xpra-html5-4.2 builds or just apply the small change by hand to xpra-html5-4.1.2?

[olifre]

@olifre Can you try one of the latest beta xpra-html5-4.2 builds or just apply the small change by hand to xpra-html5-4.1.2?

@totaam I tried with the 4.2 beta from:
https://xpra.org/beta/buster/main/binary-amd64/xpra-html5-4.2-1.deb
Patching locally is more complex at least when using the deb packages since the installed version already appears to be minified.

Sadly, I can still reproduce the problem, with the exact same behaviour, also the browser console output is the same, just the version number changed to 4.2. I also checked the content of the deb package and found:

Utilities.isSafari()&&(PyRencoder=null),this.encryption&&(PyRencoder=null),this._update_capabilities( ....

which I think is the minified version of your change. I find this also in the installed version, and have purged the browser cache.
Note I needed to add [trusted=yes] to the repo file since beta repositories do not appear to be signed.

[totaam]

Patching locally is more complex at least when using the deb packages since the installed version already appears to be minified.

Ah, yes. You can just remove the minified versions and the non-minified one will be used.

Sadly, I can still reproduce the problem,..

Oops, sorry. Looks like I forgot half of the fix: the first commit had disabled receiving AES with rencode (by telling the server not to use rencode), the latest commit also disables it when sending with AES.
It's possible that only the second one is really needed. I haven't checked this yet.

Note I needed to add [trusted=yes] to the repo file since beta repositories do not appear to be signed.

Yes, something weird happened (Xpra-org/xpra#3106), should be OK now. Tested with Fedora 33 and Debian Buster.

[olifre]

Ah, yes. You can just remove the minified versions and the non-minified one will be used.

Thanks!
Using the latest 4.2 beta, I just replaced the shipped Protocol.js with the one from your last commit for this test, and now the issue is indeed fixed, many thanks 😄 .

It's possible that only the second one is really needed. I haven't checked this yet.

I've replaced my Client.js with a version from before your earlier commit, i.e. just keeping the second one, and it still works — so indeed it seems that only the second one is really needed.

Yes, something weird happened (Xpra-org/xpra#3106), should be OK now. Tested with Fedora 33 and Debian Buster.

Thanks, I can confirm this is now also fine again for me 👍 .

[totaam]

FYI: #84 which also works with LZ4: #8