Could someone take over my patch? :)
> I'm quite busy doing other things, and it isn't my role to work on such
> things directly. I often send a patch here and there when I see fit, but
> here, I don't think I'm the best person to do so.
>
>
I updated the patch based on the comments so far:
https:/
On 11/23/2014 06:01 AM, Jeremy Stanley wrote:
> but we shouldn't
> backport a patch which suddenly breaks someone's cloud because they
> made a conscious decision to configure it to use SSLv3 for RPC
> communication.
I'm having a hard time figuring out in which case it would make sense to
do so. H
On 23 November 2014 at 11:01, Jeremy Stanley wrote:
> On 2014-11-22 19:45:09 +1300 (+1300), Robert Collins wrote:
>> Given the persistent risks of downgrade attacks, I think this does
>> actually qualify as a security issue: not that its breaking, but
>> that SSLv3 is advertised and accepted anywh
On Nov 22, 2014, at 5:01 PM, Jeremy Stanley wrote:
> On 2014-11-22 19:45:09 +1300 (+1300), Robert Collins wrote:
>> Given the persistent risks of downgrade attacks, I think this does
>> actually qualify as a security issue: not that its breaking, but
>> that SSLv3 is advertised and accepted anyw
On 2014-11-22 16:33:52 -0500 (-0500), Donald Stufft wrote:
> I refreshed my memory and I was wrong about the specific attack.
> However the point still stands that both the rfc and respected
> folks such as Thomas porin state that you should look at the
> version negotiation as a way to selectively
On 2014-11-22 19:45:09 +1300 (+1300), Robert Collins wrote:
> Given the persistent risks of downgrade attacks, I think this does
> actually qualify as a security issue: not that its breaking, but
> that SSLv3 is advertised and accepted anywhere.
Which downgrade attacks? Outside of Web browser auth
I refreshed my memory and I was wrong about the specific attack. However the
point still stands that both the rfc and respected folks such as Thomas porin
state that you should look at the version negotiation as a way to selectively
enable new features not as a way to ensure that a connection us
I'm in my phone but rfc 2246 says that there are many ways in which an attacker
can attempt to make an attacker drop down to the least secure option they both
support. It's like the second or third paragraph of that section.
> On Nov 22, 2014, at 4:00 PM, Jeremy Stanley wrote:
>
>> On 2014-1
On 2014-11-22 13:37:55 -0500 (-0500), Donald Stufft wrote:
> Yes this. SSLv3 isn’t a “Well as long as you have newer things
> enabled it’s fine” it’s a “If you have this enabled at all it’s a
> problem”. As far as I am aware without TLS_FALLBACK_SCSV a MITM
> who is willing to do active attacks can
> On Nov 22, 2014, at 1:45 AM, Robert Collins wrote:
>
> On 22 November 2014 08:11, Jeremy Stanley wrote:
>> On 2014-11-21 12:31:08 -0500 (-0500), Donald Stufft wrote:
>>> Death to SSLv3 IMO.
>>
>> Sure, we should avoid releasing new versions of things which assume
>> SSLv3 support is present
On 22 November 2014 08:11, Jeremy Stanley wrote:
> On 2014-11-21 12:31:08 -0500 (-0500), Donald Stufft wrote:
>> Death to SSLv3 IMO.
>
> Sure, we should avoid releasing new versions of things which assume
> SSLv3 support is present in underlying libraries/platforms (it's
> unclear to me why anyone
On 2014-11-21 12:31:08 -0500 (-0500), Donald Stufft wrote:
> Death to SSLv3 IMO.
Sure, we should avoid releasing new versions of things which assume
SSLv3 support is present in underlying libraries/platforms (it's
unclear to me why anyone even thought it was good to make that
configurable to this
On Nov 21, 2014, at 1:53 PM, Thomas Goirand wrote:
> On 11/21/2014 10:38 PM, Doug Hellmann wrote:
>>
>> On Nov 21, 2014, at 4:56 AM, Thomas Goirand wrote:
>>
>>> Hi,
>>>
>>> Trying to rebuild Neutron Juno in Sid, I get so many of these failures:
>>>
>>> Traceback (most recent call last):
>>
On 11/21/2014 10:38 PM, Doug Hellmann wrote:
>
> On Nov 21, 2014, at 4:56 AM, Thomas Goirand 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/ne
> On Nov 21, 2014, at 11:51 AM, Jeremy Stanley wrote:
>
> On 2014-11-21 09:38:00 -0500 (-0500), Doug Hellmann wrote:
>> 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 iss
On 2014-11-21 09:38:00 -0500 (-0500), Doug Hellmann wrote:
> 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 sho
On Nov 21, 2014, at 4:56 AM, Thomas Goirand 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
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()
Fi
18 matches
Mail list logo