#2329 closed defect (fixed)
md5 on FIPS-enabled Linux systems
Reported by: | Eric Lemings | Owned by: | Eric Lemings |
---|---|---|---|
Priority: | minor | Milestone: | 3.0 |
Component: | platforms | Version: | 1.0.x |
Keywords: | Cc: |
Description
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.
Attachments (2)
Change History (9)
Changed 3 years ago by
Attachment: | xpra-1.0.13.fips-md5-sha256.patch added |
---|
Changed 3 years ago by
Attachment: | xpra-2.5.2.fips-md5-sha256.patch added |
---|
Xpra 2.5.2 patch for FIPS-compliant checksums
comment:1 Changed 3 years ago by
Owner: | changed from Antoine Martin to Eric Lemings |
---|
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)
comment:2 Changed 3 years ago by
How about this:
- r22933 use sha1 as fallback for window border color (no risk here)
- r22934 switch to sha1 for pixel checksum debugging feature (and only support md5 in the client - for now)
- r22935 update unit test
- r22936 try all possible hashin algorithms for matching keys (configurable via env var) and warn if one is missing
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)
comment:3 Changed 3 years ago by
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".
comment:4 Changed 3 years ago by
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.
comment:5 Changed 3 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Minor fix in r23091 + r23092 (backport to v1.0 in r23093), which also makes it possible to disable md5 using (this is useful for testing):
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
comment:6 Changed 17 months ago by
comment:7 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2329
Xpra 1.x patch for FIPS-compliant checksums