Hi Andrea, Would you be willing to add yourself as the steward for Softlayer and Docker on our Stewards [1] page?
I don’t mean to put you on the spot but I wanted to throw it out there. Regards, Everett [1] https://wiki.apache.org/jclouds/Stewards On Oct 17, 2014, at 5:19 AM, Andrea Turli <andrea.tu...@gmail.com> wrote: > +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 >>>>> >>>
