+1 (binding)
* Executed the validation script:
- Source code compiles and passes all tests
- There are no RAT violations
- Checksums match
- Signatures match
* All LICENSE and NOTICE files are correct
* I ran also LiveTests for Docker and SoftLayer:
- SoftLayer:
Tests run: 154, Failures: 15, Errors: 0, Skipped: 10
- Docker (still on 1.0 version):
Tests run: 38, Failures: 2, Errors: 0, Skipped: 26
For Docker *LiveTests: the provider needs a version bump, Docker
continues to push new version out continuously, so the next release
will have a best LiveTest coverage and will support latest Docker
Engine.
Cheers,
Andrea
On Fri, Oct 17, 2014 at 7:15 AM, Niraj Tolia <nto...@maginatics.com> wrote:
> On Thu, Oct 16, 2014 at 10:04 PM, Chris Custine <chris.cust...@gmail.com>
> wrote:
>>
>> On October 16, 2014 at 10:49:33 PM, Niraj Tolia
>> (nto...@maginatics.com(mailto:nto...@maginatics.com)) wrote:
>>> On Thu, Oct 16, 2014 at 9:43 PM, Chris Custine wrote:
>>> >
>>> > I am hoping others can confirm this, but after reading the advisory and
>>> > several commentaries on it, I can’t think of any way that this exploit
>>> > can affect a jclouds client. My interpretation is that in addition to the
>>> > man in the middle requirement to force the protocol downgrade to SSL3 and
>>> > subsequent packet modification, the exploit also requires some injection
>>> > of code onto the client that will cause the client to execute repeated
>>> > requests to an endpoint with an incrementing http path length and
>>> > decrementing body length.
>>> >
>>>
>>> No, anyone on the network path in between the client and server can
>>> initiate this attack. https://www.openssl.org/~bodo/ssl-poodle.pdf and
>>> https://www.dfranke.us/posts/2014-10-14-how-poodle-happened.html has a
>>> lot more context on this but the interesting quote is:
>>
>> This is the part that enables the exploit of SSL3, but this is not the
>> actual exploit.
>>
>>>
>>> So if an attacker that controls the network between the client and the
>>> server interferes with any attempted handshake offering TLS 1.0 or
>>> later, such clients will readily confine themselves to SSL 3.0.
>>
>> I understand that part, but this is just initiating the protocol downgrade.
>> Downgrading to SSL3 isn’t really the issue, the issue is what is done to
>> exploit that. They would still need to initiate many specifically formatted
>> requests with varying path and body lengths from the *real* client to
>> eventually resolve the encrypted attributes (from a jclouds standpoint this
>> would probably be auth headers). This means that some part of the response
>> from the actual endpoint would have to have some content that causes jclouds
>> itself to go rogue and start making these orchestrated requests to nonsense
>> urls, and with body content that is decremented to match the incrementing
>> path, and do this many times (up to 256 times for each byte) until the
>> server does not reject the SSL. If we have an flaw that allows execution of
>> arbitrary script code of some variety in jclouds, then I am suddenly worried
>> about a lot more than this exploit. :-)
>>
>
>
> Ah, I see better what you mean. Yes, from my understanding of POODLE,
> there has to be some way for the attacker to be able to get jclouds to
> generate URLs in the above scenario. We do not know all the ways in
> which jclouds users use the library and if users can control the URLs
> (say, for example, using a filename for upload that gets directly
> encoded into the filename), I wonder if that is sufficient to launch
> the attack.
>
> Cheers,
> Niraj
>
>
>> My 2 cents.
>>
>> Chris
>>
>>
>>>
>>> Cheers,
>>> Niraj
>>>
>>>
>>> >
>>> > I don’t see any opportunities to inject random script code into a jclouds
>>> > client and have it execute in a way similar to javascript in a browser,
>>> > and from what I have read, that is what it would take to make use of this
>>> > exploit.
>>> >
>>> > Hopefully other will have the opportunity to interpret this and weigh in
>>> > with their insight as well.
>>> >
>>> > Thanks,
>>> > Chris
>>> >
>>> >
>>> > --
>>> > Chris Custine
>>> >
>>> >
>>> >
>>> > On October 16, 2014 at 6:20:23 PM, Andrew Phillips
>>> > (aphill...@qrmedia.com(mailto:aphill...@qrmedia.com)) wrote:
>>> >
>>> > > > I prefer to exercise an abundance of caution and extend the vote until
>>> > > > we understand the issue.
>>> > >
>>> > > I wasn't planning to close the vote until we have more details on
>>> > > this, indeed. Obviously, the more people can help have a look at this,
>>> > > the better ;-)
>>> > >
>>> > > PR at https://github.com/jclouds/jclouds/pull/575
>>> > >
>>> > > Thanks!
>>> > >
>>> > > ap
>>> >
>>
