Open Stack

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

> On 11/21/2014 10:38 PM, Doug Hellmann wrote:
>> 
>> On Nov 21, 2014, at 4:56 AM, Thomas Goirand <zigo at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev