On FIPS-enabled Linux systems, Python's hashlib.md5() function is considered "unsafe" and does nothing except throw a ValueError? exception. A patch is attached.
Xpra 1.x patch for FIPS-compliant checksums
Xpra 2.5.2 patch for FIPS-compliant checksums
Thanks for reporting this issue. I've only just glanced at the patches so far, the patch for v2.5.x looks fine but the patch for v1.0.x will cause hard to debug failures in the authentication modules: switching to sha1 (or sha256 for some - not sure why those are different) will cause the the authentication value provided by the client to not match the one generated by the server using a different hash. (that's one of the changes since v1: clients can specify a list of hashes they support and we choose the strongest ones first)
How about this:
All of this can be backported to v2.5.x
For v1.0.x, I am tempted to add a utility method to the autentication modules for doing the hmac and just failing every time: we can't do md5 and doing something else should never match. (same for the proxy: returning an invalid string)
I started with sha256 but later realized that sha1 is sufficient but didn't update them all hence the mix-up.
A utility wrapper sounds good. These patches are provided just as examples to fix the "bug".
The untested fix for authentication modules in v1.0.x is in r22943: it will fail with a warning.
Backports for both v1.0.x and v2.5.x:
Will close after re-testing authentication with v1.0.x builds.
XPRA_NOMD5=1 xpra ...
We patch it out from
hashlib.algorithms_available only because hashlib.algorithms_guaranteed says: Note that ‘md5’ is in this list despite some upstream vendors offering an odd “FIPS compliant” Python build that excludes it.
Tested OK with version 1.0
Another related fix in r28262.
Also honour the flag in the automatic border colour code: r28263.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2329