You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Multiprocessing UNIX socket connection: client freeze if authkey is an empty byte string #88118
However, in the special case that key=b"" the doesn't print anything, and can only be interrupted with Ctrl+C.
key=None doesn't have that issue.
Note that this issue does happen when the client uses the key b"" and the server uses the key None, but the program works normally if the reverse situation.
c = self._listener.accept()
if self._authkey:
deliver_challenge(c, self._authkey)
answer_challenge(c, self._authkey)
return c
If I change the Listener to:
if self._authkey is not None:
deliver_challenge(c, self._authkey)
answer_challenge(c, self._authkey)
return c
it works.
The docs say:
"""
If authkey is given and not None, it should be a byte string and will be used as the secret key for an HMAC-based authentication challenge. No authentication is done if authkey is None. AuthenticationError is raised if authentication fails. See Authentication keys.
"""
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?
miguendes commented on May 3, 2021
miguendesmannequin
Mannequin
More actions
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
we denote by H, and a secret key K.
...
The authentication key K can be of any length up to B, the
block length of the hash function."
Activity
anon01 commentedon Apr 27, 2021
When I run this code (on a UNIX system with temporary directory
/tmp/):it prints out "receive data" normally.
However, in the special case that
key=b""the doesn't print anything, and can only be interrupted with Ctrl+C.key=Nonedoesn't have that issue.Note that this issue does happen when the client uses the key
b""and the server uses the keyNone, but the program works normally if the reverse situation.Python version: Python 3.9.3.
miguendes commentedon May 1, 2021
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:
"""
If authkey is given and not None, it should be a byte string and will be used as the secret key for an HMAC-based authentication challenge. No authentication is done if authkey is None. AuthenticationError is raised if authentication fails. See Authentication keys.
"""
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?
miguendes commentedon May 3, 2021
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
we denote by H, and a secret key K.
...
The authentication key K can be of any length up to B, the
block length of the hash function."
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.
#25845
gpshead commentedon Feb 27, 2024
A bit of an ironic issue as using an empty key seems kind of pointless... but thanks for the edge case fix! :)
gh-88118: Fix some test_multiprocessing flakiness. (#116434)
pythongh-88118: Fix some test_multiprocessing flakiness. (pythonGH-11…
pythongh-88118: Fix some test_multiprocessing flakiness. (pythonGH-11…
[3.12] gh-88118: Fix some test_multiprocessing flakiness. (GH-116434) (…
[3.11] gh-88118: Fix some test_multiprocessing flakiness. (GH-116434) (…
pythongh-88118: Fix some test_multiprocessing flakiness. (python#116434)
pythongh-88118: Fix some test_multiprocessing flakiness. (python#116434)