What’s your wiki.apache.org username? I just need to add you to https://wiki.apache.org/jclouds/ContributorsGroup
Everett On Oct 17, 2014, at 9:33 AM, Andrea Turli <andrea.tu...@gmail.com> wrote: > Everett, > > yeah no problem :) > Actually I tried to edit that wiki page some time ago but I couldn't > find my way, then I forgot to ask for help. > > Could you help me? > > Best, > Andrea > > On Fri, Oct 17, 2014 at 4:26 PM, Everett Toews > <everett.to...@rackspace.com> wrote: >> 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 >>>>>>> >>>>> >>
