-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
Multiprocessing UNIX socket connection: client freeze if authkey is an empty byte string #88118
Comments
When I run this code (on a UNIX system with temporary directory
it prints out "receive data" normally. However, in the special case that
Note that this issue does happen when the client uses the key Python version: Python 3.9.3. |
I tried debugging this and from what I can see it's because there's an if that checks if the authkey is not None in the Client constructor: https://github.com/python/cpython/blob/v3.9.4/Lib/multiprocessing/connection.py#L512
Whereas in the Listener, the check is different: https://github.com/python/cpython/blob/v3.9.4/Lib/multiprocessing/connection.py#L469
If I change the Listener to:
it works. The docs say: """ Now the question is, if None is OK because no auth will be done what about empty bytes? Can it be used as secret key? If empty bytes is not accepted shouldn't Listener/Client raise an exception in the constructor? |
I had a look at the HMAC RFC and apparently empty bytes sequence can be used as secret key. "The definition of HMAC requires a cryptographic hash function, which ... The authentication key K can be of any length up to B, the https://tools.ietf.org/html/rfc2104.html#section-2 Assuming that is the case, the fix would be to change the Listener to:
I created a PR for that, if anyone can review it, I appreciate it. |
A bit of an ironic issue as using an empty key seems kind of pointless... but thanks for the edge case fix! :) |
Fix some test_multiprocessing flakiness. Potentially introduced by #25845 not joining that thread likely leads to recently observed "environment changed" logically passing but overall failing tests seen on some buildbots similar to: ``` 1 test altered the execution environment (env changed): test.test_multiprocessing_fork.test_processes 2 re-run tests: test.test_multiprocessing_fork.test_processes test.test_multiprocessing_forkserver.test_processes ```
…6434) Fix some test_multiprocessing flakiness. Potentially introduced by python#25845 not joining that thread likely leads to recently observed "environment changed" logically passing but overall failing tests seen on some buildbots similar to: ``` 1 test altered the execution environment (env changed): test.test_multiprocessing_fork.test_processes 2 re-run tests: test.test_multiprocessing_fork.test_processes test.test_multiprocessing_forkserver.test_processes ``` (cherry picked from commit ea1803e) Co-authored-by: Gregory P. Smith <greg@krypto.org>
…6434) Fix some test_multiprocessing flakiness. Potentially introduced by python#25845 not joining that thread likely leads to recently observed "environment changed" logically passing but overall failing tests seen on some buildbots similar to: ``` 1 test altered the execution environment (env changed): test.test_multiprocessing_fork.test_processes 2 re-run tests: test.test_multiprocessing_fork.test_processes test.test_multiprocessing_forkserver.test_processes ``` (cherry picked from commit ea1803e) Co-authored-by: Gregory P. Smith <greg@krypto.org>
…GH-116440) Fix some test_multiprocessing flakiness. Potentially introduced by #25845 not joining that thread likely leads to recently observed "environment changed" logically passing but overall failing tests seen on some buildbots similar to: ``` 1 test altered the execution environment (env changed): test.test_multiprocessing_fork.test_processes 2 re-run tests: test.test_multiprocessing_fork.test_processes test.test_multiprocessing_forkserver.test_processes ``` (cherry picked from commit ea1803e) Co-authored-by: Gregory P. Smith <greg@krypto.org>
…GH-116441) Fix some test_multiprocessing flakiness. Potentially introduced by #25845 not joining that thread likely leads to recently observed "environment changed" logically passing but overall failing tests seen on some buildbots similar to: ``` 1 test altered the execution environment (env changed): test.test_multiprocessing_fork.test_processes 2 re-run tests: test.test_multiprocessing_fork.test_processes test.test_multiprocessing_forkserver.test_processes ``` (cherry picked from commit ea1803e) Co-authored-by: Gregory P. Smith <greg@krypto.org>
Fix some test_multiprocessing flakiness. Potentially introduced by python#25845 not joining that thread likely leads to recently observed "environment changed" logically passing but overall failing tests seen on some buildbots similar to: ``` 1 test altered the execution environment (env changed): test.test_multiprocessing_fork.test_processes 2 re-run tests: test.test_multiprocessing_fork.test_processes test.test_multiprocessing_forkserver.test_processes ```
Fix some test_multiprocessing flakiness. Potentially introduced by python#25845 not joining that thread likely leads to recently observed "environment changed" logically passing but overall failing tests seen on some buildbots similar to: ``` 1 test altered the execution environment (env changed): test.test_multiprocessing_fork.test_processes 2 re-run tests: test.test_multiprocessing_fork.test_processes test.test_multiprocessing_forkserver.test_processes ```
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs
The text was updated successfully, but these errors were encountered: