On Nov 21, 2014, at 1:53 PM, Thomas Goirand <tho...@goirand.fr> wrote:

> On 11/21/2014 10:38 PM, Doug Hellmann wrote:
>> 
>> On Nov 21, 2014, at 4:56 AM, Thomas Goirand <z...@debian.org> wrote:
>> 
>>> Hi,
>>> 
>>> Trying to rebuild Neutron Juno in Sid, I get so many of these failures:
>>> 
>>> Traceback (most recent call last):
>>> File
>>> "/home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/unit/agent/linux/test_ovs_lib.py",
>>> line 137, in setUp
>>>   super(OVS_Lib_Test, self).setUp()
>>> File
>>> "/home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py",
>>> line 128, in setUp
>>>   self.setup_rpc_mocks()
>>> File
>>> "/home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py",
>>> line 150, in setup_rpc_mocks
>>>   self.messaging_conf = messaging_conffixture.ConfFixture(CONF)
>>> File "/usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py",
>>> line 48, in __init__
>>>   'oslo.messaging._drivers.impl_rabbit', 'rabbit_opts')
>>> File "/usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py",
>>> line 24, in _import_opts
>>>   __import__(module)
>>> File
>>> "/usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py",
>>> line 420, in <module>
>>>   class Connection(object):
>>> File
>>> "/usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py",
>>> line 497, in Connection
>>>   "sslv3": ssl.PROTOCOL_SSLv3
>>> AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'
>>> 
>>> Having a deeper look into the issue, I saw the following changelog in
>>> Python 2.7 (this was uploaded 3 days ago in Sid):
>>> 
>>> * Allow building and testing without SSLv3 support (Kurt Roeckx).
>>>   Closes: #768611.
>>> 
>>> Having a closer look at oslo.messaging reveals this in
>>> oslo/messaging/_drivers/impl_rabbit.py:
>>> 
>>>   _SSL_PROTOCOLS = {
>>>       "tlsv1": ssl.PROTOCOL_TLSv1,
>>>       "sslv23": ssl.PROTOCOL_SSLv23,
>>>       "sslv3": ssl.PROTOCOL_SSLv3
>>>   }
>>> 
>>> Removing the last line (which makes the PROTOCOL_SSLv3 not used anymore)
>>> fixed the build of Neutron.
>>> 
>>> Obviously, what happened in Debian is that Kurt Roeckx, the maintainer
>>> of openssl, removed support for SSLv3, because of potential security
>>> issues (downgrade attacks), which were revealed by the infamous POODLE bug.
>>> 
>>> Obviously also, we shall remove PROTOCOL_SSLv3 from one of the possible
>>> options in oslo.messaging.
>>> 
>>> I thought this deserved explanations so that the review here can be
>>> understood better:
>>> https://review.openstack.org/136278
>> 
>> The patch drops support entirely, but as Brant points out that isn’t 
>> backwards-compatible. I’d be interested to hear from the security team about 
>> whether the security issues trump the backwards compatibility issues here or 
>> if we should maintain optional support (that is, allow v3 if we detect that 
>> we can use it because the symbol is present). 
>> 
>> Thomas, can you get one or two of the security team to comment on the patch?
>> 
>> Doug
> 
> Do you mean the Debian security team? Or the OpenStack one?

Sorry, I meant the OpenStack team.

> 
> For Debian, what happened is that Kurt, who maintains OpenSSL in Debian,
> simply disabled it. He sent a patch for Python to make build and work
> without SSLv3 support in OpenSSL. So I believe that in Debian, we want
> SSLv3 to be completely gone. It is my view as well that we shouldn't
> continue to support it at all.
> 
> Also, SSLv3 is in oslo-incubator (in all branches, including master,
> stable/juno and stable/icehouse). We should remove it completely from
> there as well, or at least allow it to work without it in Python (that
> is, without ssl.PROTOCOL_SSLv3 being defined).

We’re in the process of removing sslutils from the incubator entirely. 
https://review.openstack.org/#/c/126505/

> 
> I don't really mind if we continue to allow it, but at least we should
> move fast to have oslo-incubator fixed. I will need to do something fast
> for Icehouse in Sid/Jessie, as we're in freeze mode. Best would be to
> have the issue resolved before the next point release (currently set for
> May 14 2015).

Sure. See my comments on your current review for what I think we need to do to 
handle the backwards-compatibility issues more clearly.

Doug

> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to