bpo-17258: use sha256 instead of md5 within multiprocessing.connection #16264
Conversation
Within multiprocessing.connection, deliver_challenge() and answer_challenge() use hmac for a challenge/response, however hmac implicitly defaults to using MD5, which fails under FIPS mode. Hardcode the digest value to sha256.
|
cc @tiran |
tiran
left a comment
There was a problem hiding this comment.
I would prefer a more flexible solution that allows us to change algorithms more easily in the future and perhaps allows different auth mechanisms than HMAC challenge and response.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
As fas as I can see, changing the algorithm would mean setting
I don't see how this PR is blocking someone from working on that. |
|
The change breaks backward compatibility. multiprocessing supports distributed computing across multiple machines and works with multiple Python versions. With the change a controller with Python 3.9 would no longer be able to talk to a 3.8 server or the other way around. |
|
@tiran What would you propose to move this forward, essentially moving away from md5? Any approaches that would make sense? Something like implementing a client-server handshake negotiation to agree on a hash? |
|
Closing this. Superseded by #20380 |
Within multiprocessing.connection, deliver_challenge() and
answer_challenge() use hmac for a challenge/response, however
hmac implicitly defaults to using MD5, which fails under FIPS
mode. Hardcode the digest value to sha256.
This PR is adapted from the patch provided at bpo-17258 and pulled from encukou@b819ca6
https://bugs.python.org/issue17258