New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gh-61460: Stronger HMAC in multiprocessing #20380
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Christian Heimes <christian@python.org>
I'm just wondering here, but is this still waiting for reviews before it can be merged? |
Why jump through all the hoops to specify the digest in the protocol? Don't we always control both ends of the connection so there should never be a situation where negotiation and understanding of what was used is needed?
That'd be a lot less complicated.
And not prone to the potential problem this has of always stooping to the lowest level decided upon out by the challenge initiator rather than requiring a specific hash to be used on the channel.
Misc/NEWS.d/next/Library/2020-05-25-12-42-36.bpo-17258.lf2554.rst
Outdated
Show resolved
Hide resolved
The protocol modification idea remains, but we now take advantage of the message length as an indicator of legacy vs modern protocol version. No more regular expression usage. We now default to HMAC-SHA256, but do so in a way that will be compatible when communicating with older clients or older servers. No protocol transition period is needed. More unittests to verify these claims remain true are required.
See also #61460
Signed-off-by: Christian Heimes christian@python.org
#61460 formerly known as https://bugs.python.org/issue17258