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

2016-02-16 Thread Robert Collins 
I suggest:
 - pin anything that moves
 - start being strict ourselves to prepare for moving
 - work with paramiko to help them move

Sadly Python doesn't have either-or dependencies as yet, so we're
going to be in the position of having to override pip for some time
during the migration process.

-Rob

On 15 February 2016 at 11:16, Davanum Srinivas  wrote:
> 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
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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

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

2016-02-16 Thread Beliveau, Ludovic 
I'm getting these nova tox errors now (from pip-missing-reqs):
Missing requirements:
nova/crypto.py:29 dist=pycrypto module=Crypto.PublicKey.RSA

I think requirements.txt should now include pycrypto ?  Or am I missing 
something.

Thanks,
/ludovic

-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: Sunday, February 14, 2016 5:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto 
vs pycryptodome

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


--
Davanum Srinivas :: https://twitter.com/dims

__
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

__
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

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

2016-02-15 Thread Davanum Srinivas 
Douglas,

Which means we should make sure pysaml2 and paramiko do switch to the
" pyca/cryptography" ASAP. However, what do we do in the mean time?

-- Dims

On Mon, Feb 15, 2016 at 1:30 PM, Douglas Mendizábal
 wrote:
> -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 :
 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> -BEGIN PGP

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

2016-02-15 Thread Douglas Mendizábal 
-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 :
>>> 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-requ...@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-requ...@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

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

2016-02-15 Thread Douglas Mendizábal 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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 :
>> 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/0e4f5fa48b1965b269f69bd383bbfb
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/Publ
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-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJWwhehAAoJEB7Z2EQgmLX7ZvwP/1a4vWgVeryvJGXNP/O5aoml
hvlvJCcJrW0vyRfycQBN4nNSVZLrhjxy+5XIW86/OjfDVnSci2hdI+zKwoGpSrDM
NEi80j6ll31QLBQMDVlNvwv/5DGukJ1fjN35IhHMwWYCBBOU7VGFUuBhdwi47vW4
qHI99Rkf1P6wpVygPTRMye0Z9T249XiYtDckverqEGT7jsYu0SBbK3ti/zbcSmXw
upSAQRYa9GIklVe3GMd0CiD933YsxpCOqGtuhtwslPlbCh0Pd23FbRLFf+Sufojl
9hky7dbl/gKFjf2tHaenYdFun+mlP7bKpYzJ+Hghszw3BACpXeK+U+dcdg9wJTgy
POejML3Kuo5jYnCmWahWuNCuSHepace2E36nm0hsAcC5ntePrKHI31fo9nmiyz/4
1XmUQ96HEl2CUVWFpcYbencf+412o3RGpETita26gUOK+iiBemEA4WWmfAI+9uo0
v3b014Jpyth25CV6uB4vSotbk5p191EBPaUVR7kMhMfx2YJZFWMXD+Hifi72vWjs
oSpoojTiDCj6ctEocTGGnnqMSaO8bNjLOk5fvO0IyLcEjkLrMZEeXS8UsCsyMuQ5
XNncop2G6ABWbrrkpwkAJMoOoHqjQ48DDlPd4qHAJueYh6ENJr/WOVftG7htESo/
BTUtLmCOHdtR05xVf3Hn
=t6oe
-END PGP SIGNATURE-

__
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

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

2016-02-15 Thread Flavio Percoco 

On 14/02/16 17:16 -0500, Davanum Srinivas wrote:

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/


I'm not opposed to this as a short term solution.

Flavio


Example for Barbican : https://review.openstack.org/#/c/280014/

What do you think?

Thanks,
Dims


--
Davanum Srinivas :: https://twitter.com/dims

__
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


--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

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

2016-02-15 Thread Haïkel 
2016-02-14 23:16 GMT+01:00 Davanum Srinivas :
> 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

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

2016-02-14 Thread Davanum Srinivas 
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


-- 
Davanum Srinivas :: https://twitter.com/dims

__
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