Open stefnet00 opened 3 years ago
Both interesting and very bizarre. Thanks for the report. Yet another CentOS issue.
So bottom line why this happens: zugbruecke
runs on two Python interpreters. A Linux-version (in your case from CentOS) and a Windows-version (unmodified and straight from python.org). I try to make things a little secure by authenticating the two interpreters against one another. After all, I am running RPC-servers and I do not want anybody to be able to send arbitrary commands to them. In your case, this authentication fails.
It appears that CentOS applied its own patch, essentially swapping the old & insecure MD5-hash algorithm for something else (in the multiprocessing module, at least). In standard CPython 3.9, the latest version, it's still MD5, by the way. CentOS, by default, uses a different hashing algorithm in this place, which causes a "conflict" with the original implementation in the Windows-version of the interpreter. That's why you are getting those authentication errors.
Looking at the relevant CentOS package, it appears that it has been patched to use sha256
(see line 47). Unfortunately, this is not even configurable. Bottom line: Nice idea by the CentOS folks. MD5 is insecure, yes. But this patch makes CPython on their systems incompatible to the rest of the world. It'd file a bug report against CentOS and ask if HMAC_DIGEST_NAME
in this file could be made configurable e.g. through an environment variable.
As a temporary, and very ugly patch on zugbruecke
's side, you could deactivate the authentication. Remove the authkey
parameters from function calls here and here (and make sure your computer is properly firewalled). Alternatively, you could of cause also patch the relevant lines in connection.py
in the Windows-Python interpreter to use sha256
like your CentOS system does.
Thanks for the quick response. I now understand the problem a bit more. So they made CentOS more secure but incompatible with other systems. The idea of changing it to sha256 in the Windows-Python interpreter sounds good. I'll try this.
Any luck with patching the Windows-Python interpreter's standard library?
Not yet. I was patching the CentOS library instead... It undermines the higher security but it was easier. Just copied the standard multiprocessing package to my user packages and changed back to md5 (HMAC_DIGEST_NAME='md5'
). That was successful.
Hi all,
I'am using zugbrucke on different machines to handle Windows DLL files. On CentOS with Python 3.6.8 zugbruecke fails with often repeated error message (over 2000 times):
On openSUSE Leap 15.2 with Python 3.6.10 there is no error and it runs flawlessly.
There is a difference in the multiprocessing.py in those two Python versions just before the error occurs.
openSUSE Leap 15.2 / multiprocessing.py:line721 (Python3.6.10)
CentOS / multiprocessing.py:line725 (Python3.6.8)
It's curious, on github this file is different for Python3.6.8 [1]
I'm not sure if this is a bug in zugbruecke or if it is related to the older version of python (multiprocessing). The example for multiprocessing connections was working on CentOS [2].
I solved the problem by using the multiprocessing module of openSUSE Leap 15.2 on the machine with CentOS7. It's just a workaround but the best I could find for now.
[1] https://github.com/python/cpython/blob/v3.6.8/Lib/multiprocessing/connection.py#L721
[2] https://docs.python.org/3.6/library/multiprocessing.html#multiprocessing.connection.wait