[openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

Douglas Mendizábal douglas.mendizabal at rackspace.com
Mon Feb 15 18:30:09 UTC 2016


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

One more thing: I forgot to point out that pyca/cryptography is
already part of global-requirements. [1]

- - Douglas Mendizábal

[1]
http://git.openstack.org/cgit/openstack/requirements/tree/global-require
ments.txt#n25

On 2/15/16 12:24 PM, Douglas Mendizábal wrote:
> I had not previously heard of pycryptodome. Is this supposed to be 
> a drop-in replacement for pycrypto?  If so then it sounds like 
> they're doing a terrible job of it.
> 
> The plan for Barbican has been to wait for pyca/cryptography [1] to
> add support for the apis we needed to be able to drop our pycrypto
> dependency.  I'll have to double check the latest pyca/cryptography
> notes, but I do believe it's at a point now where it can be used in
> Barbican to replace pycrypto. This would be the preferred fix for
> us.
> 
> AFAIK the paramiko folks were going to adopt pyca/cryptography as 
> well, so it appears that pycryptodome support will not be merged 
> there either. [2]
> 
> Additionaly, bespoke pure-python cryptography gives me the heebie 
> jeebies, so I would strongly recommend to move all cryptographic 
> work to use pyca/cryptography instead of pycryptodome.
> 
> - Douglas Mendizábal
> 
> [1] https://cryptography.io/en/latest/ [2] 
> https://github.com/paramiko/paramiko/pull/646
> 
> On 2/15/16 6:44 AM, Haïkel wrote:
>> 2016-02-14 23:16 GMT+01:00 Davanum Srinivas <davanum at 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/0e4f5fa48b1965b269f69bd383bbf
b
>
>>>
>>> 
de6b41ac63
>>> 
>>> 
>>> 
>>> 
> 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/Pub
l
>
>>>
>>> 
icKey/RSA.py#L405
>>> 
>>> 
>>> 
>>> 
> https://github.com/dlitz/pycrypto/blob/master/lib/Crypto/PublicKey/RSA
.p
>
>
> 
y#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-request at lists.openstack.org?subject:unsubscribe 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>>
>> 
> 
> ______________________________________________________________________
____
>
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWwhkqAAoJEB7Z2EQgmLX7FaoP/17xVW32kefsDZi48xDvKzul
4IXIOcImSPNQX5FEDi6A9Q/TrTQPmyZWLYA1Ua+3dKG7fZoQ5r/cFgLCtX/gw3q/
E2rtCJxdaYfg6AYUCeLJrtYifio7eyVGp8PBTNSF8x4vTQu3qfKYYEvuTlevOrAr
RTXgjfDq8Dpw1U1yIgmu+civN22TJIB0+drM2RDHvndDNsHzLRdFv0OIaCzDEyP0
Ao5m5cjr5DAOGUwA5r2r+LAMFDe0malvC0jAAmR0u+GC2W2ys18IVvvvIXSMY8u2
Sd9W1VHw2e3A98Ij8Zn9RHXU+LCNb0ms0Mf6Z+ArNYQYeZkDCDAFjpXYfnR0Wvod
4Bw8gvdUPPPereprNiobaSC/y8TwaYX0CbR4mmmKxCQaFhpHOndh4i/Xg42yorbd
PBGjQ2N+1AHTTndPdgTI4goOi1mBKmXjRS/DDmtt1iVm2KR8SKQukAjhTHVzK1dr
5AZqtI8UjB4lgAlmz8+jIXqaCAnnv61OcEfoENArxuKO0OGCaQDTuz/osbuw09Ew
4wZQ2RjzGwriabGEGMH+kiYXaNZ1tVEqnE5d0gmk6W5yhm0o3ixKos+Chmie6uCd
UXzZaINm0xxhyxCkWujFraM6yyhhr250wiYWaAXl6BQQUnev65G3L3Oi3Ffyb2mN
NdBFZPSAuLFv0Eodoywj
=4Zzk
-----END PGP SIGNATURE-----



More information about the OpenStack-dev mailing list