Summary: | net-mgmt/netbox: conflict with py-salt: py-pycrypto conflicts with py-pycryptodome | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | O. Hartmann <ohartmann> | ||||
Component: | Individual Port(s) | Assignee: | Kai Knoblich <kai> | ||||
Status: | Closed Not A Bug | ||||||
Severity: | Affects Many People | CC: | christer.edwards, kai, koobs, pi, trix | ||||
Priority: | --- | ||||||
Version: | Latest | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
See Also: |
https://github.com/dlitz/pycrypto/issues/173 https://github.com/netbox-community/netbox/issues/1527 https://github.com/saltstack/salt/pull/45971 https://github.com/netbox-community/netbox/pull/3690 https://github.com/Legrandin/pycryptodome/issues/89 https://github.com/netbox-community/netbox/issues/3689 https://github.com/saltstack/salt/issues/52674 |
||||||
Attachments: |
|
Description
O. Hartmann
2019-11-12 10:58:30 UTC
(In reply to O. Hartmann from comment #0) Thank you for the report. It's indeed an interesting case of a Python package collision. Here are some quick facts about the related Python packages: security/py-pycrypto: ~~~~~~~~~~~~~~~~~~~~~ The project seems to be dead as the last update was in 2013. (see Github issue #173) security/py-pycryptodome: ~~~~~~~~~~~~~~~~~~~~~~~~~ This a fork of security/py-pycrypto which is actively maintained and can be used as a drop-in replacement for security/py-pycrypto. The trade off: security/py-pycrypto and security/py-cryptodome cannot coexist because both use the same package name (= "Crypto"). security/py-pycryptodomex: ~~~~~~~~~~~~~~~~~~~~~~~~~~ Like security/py-cryptodome (= same upstream) but uses a different package name (= "Cryptodome" instead "Crypto") thus it can coexist with security/py-pycrypto. Let's go over to NetBox and Salt: net-mgmt/netbox: ~~~~~~~~~~~~~~~~ Upstream switched from security/py-pycrypto to security/py-pycryptodome in 2017. (see GitHub issue #1527) sysutils/py-salt: ~~~~~~~~~~~~~~~~~ The requirement for security/py-pycrypto is pulled in via the ZEROMQ or TCP options. The ZEROMQ option is also set as default one and reflects the actual requirements by upstream as given in sysutils/py-salt's 'requirements/zeromq.txt': > # PyCrypto has issues on Windows, while pycryptodomex does not > pycrypto>=2.6.1; sys.platform != 'win32' > pycryptodomex; sys.platform == 'win32' There was a PR (see Github pull request #45971) in 2018 for the ZeroMQ dependency to use security/py-cryptodome in favor of security/py-pycrypto. But that PR was then closed after some discussion because upstream had tried it a while ago which led to some problems due a bug with a specific version of security/py-pycryptodome. Conclusion: ~~~~~~~~~~~ Because sysutils/py-salt is IMHO a pretty complex and frequently used port that need good care a patching of its 'requirements/zeromq.txt' is not trivial. I did also some quick comparison of the code: net-mgmt/netbox: ~~~~~~~~~~~~~~~~ > $ grep -r -e Crypto ./netbox-2.6.7/* |wc -l > 8 sysutils/py-salt: ~~~~~~~~~~~~~~~~~ > $ grep -r -e Crypto ./salt-2019.2.2/ |wc -l > 244 So I'll create a PR for NetBox that switches from security/py-cryptodome to security/py-cryptodomex as it seems the best (and quickest) option to solve the issue. Created attachment 209127 [details]
netbox-switch-to-py-pycryptodomex.patch
Attached is a patch that switches all relevant code to security/py-pycryptodomex .
My tests were successful so far:
- Login/Logoff -> OK
- Unlock/Lock secrets via private key -> OK
- Create new user key pair -> OK
- Active new user key pair -> OK
- Unlock/Lock secrets with new user key pair -> OK
I'll upstream that patch with some additional changes (related to documentation) as soon as possible.
Upstream of Netbox closed my PR without merging it. I asked again if the decision could be reconsidered but I guess the odds aren't very high. I'll use then the set of patches attached in this PR for a while to get the issue with the Python package collision resolved. Even if it's means additional QA work in the future with every update of Netbox. From a long-term perspective the developers of Salt should really try again to switch fully from security/py-pycrypto to security/py-cryptodome or security/py-cryptodomex. (In reply to O. Hartmann from comment #0) Did you already have the opportunity to test the attached patch? As already mentioned in comment #2 there shouldn't be any problems with switching from `pycryptodome` to `pycryptodomex`. Comment on attachment 209127 [details]
netbox-switch-to-py-pycryptodomex.patch
Pull my proposed patch for net-mgmt/netbox back as it wasn't accepted by upstream and I won't have always the time to do full QA against an unsupported version of net-mgmt/netbox.
After some thinking and internal discussions I close this bug as "not a bug" because there's little we can do to resolve the issue from a Ports related perspective. There's still some confusion (in the Ports and Python world) about the existence of both security/py-pycryptodome and security/py-pycryptodomex ports. While security/py-pycryptodome is meant as a drop-in replacement for security/py-pycrypto that seems to be no longer 100% true due some API incompatibilities (see also issue #89). And security/py-pycryptodomex seems to be hardly used in the Python world at all. To keep it short: - The problem can only be resolved at upstream level. - Upstream of security/py-pycryptodome should start using it's own namespace (= "Cryptodome" instead "Crypto") and make the security/py-pycryptodomex package obsolete. OR - Upstream of sysutils/py-salt tries again to fully abandon security/py-pycrypto (remove 'pycrypto' from the requirements for ZeroMQ). According to ##52674 (https://github.com/saltstack/salt/issues/52674 - "PyCryptodome as replacement for PyCrypto", Salt _can_ use security/py-pycryptodome, but doesn't do to pycrypto being mentioned in the requirements.txt file for ZeroMQ (even though it may or may not use it directly). From the issue text: ... and there is a picking[sic] order as to which package is used as follows: PyCrypto - basic level PyCryptodomx - preferred over PyCrypto if installed M2Crypto - preferred over PyCryptodome and PyCrypto if installed Although 52674 is closed, David Murphy (dmurphy18) goes on to talk about how this will likely be revisited once Python2 has reached end-of-life (in a little under a month and a half at this writing) -- around the Neon release (probably in 2020). |