2016-02-14 23:16 GMT+01:00 Davanum Srinivas <dava...@gmail.com>: > Hi, > > Short Story: > pycryptodome if installed inadvertently will break several projects: > Example : https://review.openstack.org/#/c/279926/ > > Long Story: > There's a new kid in town pycryptodome: > https://github.com/Legrandin/pycryptodome > > Because pycrypto itself has not been maintained for a while: > https://github.com/dlitz/pycrypto > > So folks like pysaml2 and paramiko are trying to switch over: > https://github.com/rohe/pysaml2/commit/0e4f5fa48b1965b269f69bd383bbfbde6b41ac63 > https://github.com/paramiko/paramiko/issues/637 > > In fact pysaml2===4.0.3 has already switched over. So the requirements > bot/script has been trying to alert us to this new dependency, you can > see Nova fail. > https://review.openstack.org/#/c/279926/ > > Why does it fail? For example, the new library is strict about getting > bytes for keys and has dropped some parameters in methods. for > example: > https://github.com/Legrandin/pycryptodome/blob/master/lib/Crypto/PublicKey/RSA.py#L405 > https://github.com/dlitz/pycrypto/blob/master/lib/Crypto/PublicKey/RSA.py#L499 > > Another problem, if pycrypto gets installed last then things will > work, if it pycryptodome gets installed last, things will fail. So we > definitely cannot allow both in our global-requirements and > upper-constraints. We can always try to pin stuff, but things will > fail as there are a lot of jobs that do not honor upper-constraints. > And things will fail in the field for Mitaka. > > Action: > So what can we do? One possibility is to pin requirements and hope for > the best. Another is to tolerate the install of either pycrypto or > pycryptodome and test both combinations so we don't have to fight this > battle. > > Example for Nova : https://review.openstack.org/#/c/279909/ > Example for Glance : https://review.openstack.org/#/c/280008/ > Example for Barbican : https://review.openstack.org/#/c/280014/ > > What do you think? > > Thanks, > Dims >
This is annoying from a packaging PoV. We have dependencies relying on pycrypto (e.g oauthlib used by keystone, paramiko by even more projects), and we can't control the order of installation. My 2 cts will be to favor the latter solution and test both combinations until N or O releases (and then get rid of pycrypto definitively), so we can handle this gracefully. Regards, H. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
