You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Andrew Phillips <ap...@qrmedia.com> on 2014/10/11 18:15:39 UTC
[VOTE] Release Apache jclouds 1.8.1 RC1
Hello,
This is the first release candidate for Apache jclouds 1.8.1.
Please use the separate [DISCUSS] thread for anything but votes.
It fixes the following issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12327548&styleName=Html&projectId=12314430
*** Please download, test and vote by Thursday, October 16th, 09:00
PDT / 12:00 EDT / 18:00 CET.
Note that we are voting upon the source (tag), binaries are provided
for convenience.
Source and binary files:
https://dist.apache.org/repos/dist/dev/jclouds/1.8.1-rc1/
Maven staging repos:
https://repository.apache.org/content/repositories/orgapachejclouds-1020/
(jclouds, jclouds-labs, jclouds-labs-aws, jclouds-labs-google,
jclouds-labs-openstack)
https://repository.apache.org/content/repositories/orgapachejclouds-1021/
(jclouds-chef, jclouds-karaf, jclouds-cli)
Note: upload completed from different IP addresses, hence the two repos.
The tags to be voted upon:
- jclouds -
https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=tag;h=0ce7270381cb554052ac1ea99baf9464000a3754 (SHA-1:
d17a59097377e2667c854b8238c2cce818024f30)
- jclouds-labs -
https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;a=tag;h=5bde375e996d521eb57adc9f346b679d7e03efa2 (SHA-1:
1152a38a50cb550b65336204b168b4f696e59a75)
- jclouds-labs-aws -
https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-aws.git;a=tag;h=28272367bc4c06aaf5d60ac5d276877d2a37679b (SHA-1:
7cffc5dc3b54322a319aa2b3c265564e0298b8d4)
- jclouds-labs-google -
https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;a=tag;h=eb6117508a0ebe03dd97306650cf81ac7f26500d (SHA-1:
cf58f92038e6b6ccfac09db581d5d24c885f211c)
- jclouds-labs-openstack -
https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-openstack.git;a=tag;h=d244a21b9036acb8f6a1cf6d9e383abc5f86845b (SHA-1:
26309321436df711c9a0914e46bb1205e9fc7378)
- jclouds-chef -
https://git-wip-us.apache.org/repos/asf?p=jclouds-chef.git;a=tag;h=b1081301e18a88b4f4ea647558095604416bff42 (SHA-1:
22be869dd87bd21f2a7fbe04dfa547f37012ffa3)
- jclouds-karaf -
https://git-wip-us.apache.org/repos/asf?p=jclouds-karaf.git;a=tag;h=8678a5a592614853ed8220f42ce7aac7d0c462b6 (SHA-1:
d7bfecac7e5787ba93b4cee81bcd77596fba14d2)
- jclouds-cli -
https://git-wip-us.apache.org/repos/asf?p=jclouds-cli.git;a=tag;h=368c29fc06bd24f581999e1385c10337c507528b (SHA-1:
a5c2571e405fd559641fe7ba6980f4618808fa37)
jclouds KEYS file containing PGP keys we use to sign the release:
http://www.apache.org/dist/jclouds/KEYS
[ ] +1
[ ] 0 (explain why)
[ ] -1 (explain why)
Regards
ap
Re: [VOTE] Release Apache jclouds 1.8.1 RC1
Posted by Ignasi Barrera <na...@apache.org>.
+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
* Releaser key is also present in:
https://people.apache.org/keys/group/jclouds.asc
On 11 October 2014 18:15, Andrew Phillips <ap...@qrmedia.com> wrote:
> Hello,
>
> This is the first release candidate for Apache jclouds 1.8.1.
>
> Please use the separate [DISCUSS] thread for anything but votes.
>
> It fixes the following issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12327548&styleName=Html&projectId=12314430
>
> *** Please download, test and vote by Thursday, October 16th, 09:00 PDT /
> 12:00 EDT / 18:00 CET.
>
> Note that we are voting upon the source (tag), binaries are provided for
> convenience.
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/jclouds/1.8.1-rc1/
>
> Maven staging repos:
> https://repository.apache.org/content/repositories/orgapachejclouds-1020/
> (jclouds, jclouds-labs, jclouds-labs-aws, jclouds-labs-google,
> jclouds-labs-openstack)
> https://repository.apache.org/content/repositories/orgapachejclouds-1021/
> (jclouds-chef, jclouds-karaf, jclouds-cli)
>
> Note: upload completed from different IP addresses, hence the two repos.
>
> The tags to be voted upon:
> - jclouds -
> https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=tag;h=0ce7270381cb554052ac1ea99baf9464000a3754
> (SHA-1: d17a59097377e2667c854b8238c2cce818024f30)
> - jclouds-labs -
> https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;a=tag;h=5bde375e996d521eb57adc9f346b679d7e03efa2
> (SHA-1: 1152a38a50cb550b65336204b168b4f696e59a75)
> - jclouds-labs-aws -
> https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-aws.git;a=tag;h=28272367bc4c06aaf5d60ac5d276877d2a37679b
> (SHA-1: 7cffc5dc3b54322a319aa2b3c265564e0298b8d4)
> - jclouds-labs-google -
> https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;a=tag;h=eb6117508a0ebe03dd97306650cf81ac7f26500d
> (SHA-1: cf58f92038e6b6ccfac09db581d5d24c885f211c)
> - jclouds-labs-openstack -
> https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-openstack.git;a=tag;h=d244a21b9036acb8f6a1cf6d9e383abc5f86845b
> (SHA-1: 26309321436df711c9a0914e46bb1205e9fc7378)
> - jclouds-chef -
> https://git-wip-us.apache.org/repos/asf?p=jclouds-chef.git;a=tag;h=b1081301e18a88b4f4ea647558095604416bff42
> (SHA-1: 22be869dd87bd21f2a7fbe04dfa547f37012ffa3)
> - jclouds-karaf -
> https://git-wip-us.apache.org/repos/asf?p=jclouds-karaf.git;a=tag;h=8678a5a592614853ed8220f42ce7aac7d0c462b6
> (SHA-1: d7bfecac7e5787ba93b4cee81bcd77596fba14d2)
> - jclouds-cli -
> https://git-wip-us.apache.org/repos/asf?p=jclouds-cli.git;a=tag;h=368c29fc06bd24f581999e1385c10337c507528b
> (SHA-1: a5c2571e405fd559641fe7ba6980f4618808fa37)
>
> jclouds KEYS file containing PGP keys we use to sign the release:
> http://www.apache.org/dist/jclouds/KEYS
>
> [ ] +1
> [ ] 0 (explain why)
> [ ] -1 (explain why)
>
> Regards
>
> ap
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Andrea Turli <an...@gmail.com>.
Ops, my vote is +1 (non-binding)
On Fri, Oct 17, 2014 at 12:19 PM, Andrea Turli <an...@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 <nt...@maginatics.com> wrote:
>> On Thu, Oct 16, 2014 at 10:04 PM, Chris Custine <ch...@gmail.com> wrote:
>>>
>>> On October 16, 2014 at 10:49:33 PM, Niraj Tolia (ntolia@maginatics.com(mailto:ntolia@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 (aphillips@qrmedia.com(mailto:aphillips@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
>>>> >
>>>
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Just FYI, I had more live test failures than I expected on several
> providers and while some of them are the usual image selection
> issues and normal timeouts on runscriptonnodes, etc., there were a
> few unusual ones that were happening consistently so I am digging a
> little deeper before I vote one way or another later today.
Thanks for the detailed investigations, everyone! Given these and the
ongoing discussion around JCLOUDS-753, I'm planning to wait until
Monday before closing the vote one way or the other.
Please let me know if that doesn't work for someone.
Have a good weekend, everyone!
ap
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Chris Custine <ch...@gmail.com>.
Just FYI, I had more live test failures than I expected on several providers and while some of them are the usual image selection issues and normal timeouts on runscriptonnodes, etc., there were a few unusual ones that were happening consistently so I am digging a little deeper before I vote one way or another later today.
Chris
--
Chris Custine
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Andrea Turli <an...@gmail.com>.
Everett,
not sure if I have one :)
Anyway I think it should be
andreaturli@apache.org
Thanks,
Andrea
On Fri, Oct 17, 2014 at 4:44 PM, Everett Toews
<ev...@rackspace.com> wrote:
> 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 <an...@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
>> <ev...@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 <an...@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 <nt...@maginatics.com> wrote:
>>>>> On Thu, Oct 16, 2014 at 10:04 PM, Chris Custine <ch...@gmail.com> wrote:
>>>>>>
>>>>>> On October 16, 2014 at 10:49:33 PM, Niraj Tolia (ntolia@maginatics.com(mailto:ntolia@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 (aphillips@qrmedia.com(mailto:aphillips@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
>>>>>>>>
>>>>>>
>>>
>
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Everett Toews <ev...@RACKSPACE.COM>.
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 <an...@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
> <ev...@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 <an...@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 <nt...@maginatics.com> wrote:
>>>> On Thu, Oct 16, 2014 at 10:04 PM, Chris Custine <ch...@gmail.com> wrote:
>>>>>
>>>>> On October 16, 2014 at 10:49:33 PM, Niraj Tolia (ntolia@maginatics.com(mailto:ntolia@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 (aphillips@qrmedia.com(mailto:aphillips@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
>>>>>>>
>>>>>
>>
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Andrea Turli <an...@gmail.com>.
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
<ev...@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 <an...@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 <nt...@maginatics.com> wrote:
>>> On Thu, Oct 16, 2014 at 10:04 PM, Chris Custine <ch...@gmail.com> wrote:
>>>>
>>>> On October 16, 2014 at 10:49:33 PM, Niraj Tolia (ntolia@maginatics.com(mailto:ntolia@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 (aphillips@qrmedia.com(mailto:aphillips@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
>>>>>>
>>>>
>
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Everett Toews <ev...@RACKSPACE.COM>.
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 <an...@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 <nt...@maginatics.com> wrote:
>> On Thu, Oct 16, 2014 at 10:04 PM, Chris Custine <ch...@gmail.com> wrote:
>>>
>>> On October 16, 2014 at 10:49:33 PM, Niraj Tolia (ntolia@maginatics.com(mailto:ntolia@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 (aphillips@qrmedia.com(mailto:aphillips@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
>>>>>
>>>
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Andrea Turli <an...@gmail.com>.
+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 <nt...@maginatics.com> wrote:
> On Thu, Oct 16, 2014 at 10:04 PM, Chris Custine <ch...@gmail.com> wrote:
>>
>> On October 16, 2014 at 10:49:33 PM, Niraj Tolia (ntolia@maginatics.com(mailto:ntolia@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 (aphillips@qrmedia.com(mailto:aphillips@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
>>> >
>>
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Andrew Gaul <ga...@apache.org>.
On Tue, Oct 21, 2014 at 04:41:34PM +0200, Andrew Phillips wrote:
> >In this case, the static method on HttpUrlConnection approach may be more
> >appropriate. Basically we can point to documentation about it and it
> >requires no special knowledge and can be plopped in at bootstrap code.
>
> @Andrew G: would documenting this and/or the module fix address your concerns?
>
> Given where we are, my suggestion is as follows: if we can't resolve
> -1 votes by the end of the day, I'll cancel this release and work
> towards a 1.8.1-rc2.
>
> In this case, I would like to urge all those who are uncomfortable
> with releasing rc1 at this point to improve the current proposed
> fix, since from the discussion it is clear it is currently not a
> state we would like to include in 1.8.1.
>
> If we can resolve the -1s, I would obviously still like to work on
> fixing JCLOUDS-753 as quickly as reasonably possible. Hopefully,
> with the release behind us we will a little bit more time for that.
Users should expect jclouds to have sane defaults; we should not require
code or even configuration to secure jclouds. Our users expect us to
make the best decisions on their behalf and I do not believe release
noting a potential (although unlikely) security issue represents this.
Apache releases require lazy majority, not unanimity, so a single
negative vote should not affect this release given the existing votes.
However, my -1 vote represents my best understanding of this issue and I
encourage others to vote -1 as well. While I lack the imagination to
exploit this issue, a sufficiently motivated attacker might not.
We should give users a fix in code as soon as possible, whether in a
delayed 1.8.1 or an accelerated 1.8.2. I can understand the benefits of
both approaches but the former seems like less work than an extra
release.
--
Andrew Gaul
http://gaul.org/
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Oct 21, 2014, at 9:56 AM, Adrian Cole <ad...@gmail.com> wrote:
> For those who like code...
>
> SSLContext sc = SSLContext.getInstance("TLS");
> sc.init(null, null, null);
> HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
>
> Look ma.. no guice.. no jclouds for that matter either.
>
> We shouldn't block the release; we've already squandered enough time
> on this one.
+1
Everett
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Andrew Phillips <ap...@qrmedia.com>.
Thanks for all the investigation here, Adrian. I personally also don't
believe we should block a release here, but would also like to some
comment from those who voted -1.
Regards
ap
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Adrian Cole <ad...@gmail.com>.
PS for the sake of documentation, POODLE only affects servers who
respond to sslv3. In other words jclouds users don't need to worry if
they only use hosts that don't respond to below.
echo|openssl s_client -connect $DOMAIN:443 -ssl3 2>&1|grep 'ssl
handshake failure'>&-||echo $DOMAIN should disable SSLv3
-A
On Tue, Oct 21, 2014 at 7:56 AM, Adrian Cole <ad...@gmail.com> wrote:
> For those who like code...
>
> SSLContext sc = SSLContext.getInstance("TLS");
> sc.init(null, null, null);
> HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
>
> Look ma.. no guice.. no jclouds for that matter either.
>
> We shouldn't block the release; we've already squandered enough time
> on this one.
> -A
>
> http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/HttpsURLConnection.html#setDefaultSSLSocketFactory(javax.net.ssl.SSLSocketFactory)http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/HttpsURLConnection.html#setDefaultSSLSocketFactory(javax.net.ssl.SSLSocketFactory)
>
> On Mon, Oct 20, 2014 at 5:11 PM, Adrian Cole <ad...@gmail.com> wrote:
>> PS as I certainly got into the weeds, just there.. will clarify,
>> especially as gaul raised valid points.
>>
>> 1. I think the proposed fix is distracting, so wouldn't hold back a
>> release on that.
>> 2. I don't think it would harm many, if any, if we told folks how to
>> change jclouds to not use ssl v3
>> 3. I suggested a patch, because I think that we shouldn't hold users
>> who care about poodle hostage to 1.8.1
>>
>> ...but..
>>
>> I think this should also work
>>
>> HttpsURLConnection.setDefaultSSLSocketFactory(patchedOne)
>>
>> This is probably a better quick fix, since it involves no guice. Not
>> involving guice means we can reorganize a better long-term solution,
>> and hopefully make test cases to prove it for all http drivers.
>>
>> -A
>>
>> On Mon, Oct 20, 2014 at 4:57 PM, Adrian Cole <ad...@gmail.com> wrote:
>>> Right. So, I think the safest way is to provide the information to
>>> those who wish to patch for poodle. This limits scope of the change to
>>> those interested in it, and also fixes those who aren't ready to
>>> switch to 1.8.1
>>>
>>> They would do this.
>>>
>>> contextBuilder.modules(..., new AbstractModule() {
>>> @Override public void configure(){}
>>> @Provides @Singleton Supplier<SSLContext> unpoodled() {
>>> return // favorite thing.
>>> });
>>>
>>> done. Problem answered.. scope limited.
>>>
>>> We then have bought time to think it through a bit. For example, we
>>> may want to restructure how the ssl contexts are passed around, or
>>> address other http clients in a consistent way such that client auth
>>> based apis can still work. (ex. maybe contextBuilder.sslProtocols)
>>>
>>> -A
>>>
>>> ----longer part---
>>>
>>>
>>> Apache hc was written not knowing that the default executor does this.
>>>
>>> @Inject(optional = true)
>>> protected Supplier<SSLContext> sslContextSupplier;
>>>
>>> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java#L80
>>>
>>> It started doing that because of FCGP.. Only other api that does
>>> something similar is azurecompute. These two modify the default ssl
>>> context to allow client auth and if they can't, bad things happen. It
>>> interestingly becomes the case that we need to modify the default ssl
>>> context as a part of addressing poodle!
>>>
>>> So, considering most folks don't install apachehc, we could defer
>>> addressing that, or otherwise hardcoding it. We could suggest that the
>>> most immediate fix (one that won't break any non-labs stuff), is to
>>> make this patch.
>>>
>>> contextBuilder.modules(..., new AbstractModule() {
>>> @Override public void configure(){}
>>> @Provides @Singleton Supplier<SSLContext> unpoodled() {
>>> return // favorite thing.
>>> });
>>>
>>> This will work for those who must change it, regardless of 1.8.1 or
>>> not, since all asf releases have the optionally injected ssl context
>>> supplier.
>>>
>>> Also, this limits risk only to those who install it. Remember that
>>> private cloud may not even run TLS stacks, even if it "should". It
>>> would totally suck to break folks running tests, etc. if we have a
>>> choice. Now, since we do know which clouds are "providers" we could
>>> auto-fix all public cloud services. Just saying that it isn't the case
>>> that every enterprise will patch all internal servers.
>>>
>>> WRT "untrusted" I think it confuses things to patch poodle, yet trust
>>> all certs :) That's why I suggest rolling back that part.
>>>
>>> On Mon, Oct 20, 2014 at 10:27 AM, Andrew Phillips <ap...@qrmedia.com> wrote:
>>>>> Don't mess with the untrusted one. Fix apachehc later.
>>>>
>>>>
>>>> To be clear: by this, you mean *don't* go for the change in SSLModule in
>>>> [1]? As far as I understand the code, that is also the "untrusted" context
>>>> used in ApacheHC - the one that's being modified in [1] is in case the user
>>>> is *not* looking to trust all certs [2].
>>>>
>>>> ap
>>>>
>>>> [1] https://github.com/jclouds/jclouds/pull/575/files
>>>> [2]
>>>> https://github.com/jclouds/jclouds/blob/enforce-tls/drivers/apachehc/src/main/java/org/jclouds/http/apachehc/config/ApacheHCHttpCommandExecutorServiceModule.java#L114-L119
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Adrian Cole <ad...@gmail.com>.
Kindof thinking this should have been on the discuss thread..
Anyway, the critical part of testing any patch is validating that
sslSocket.getEnabledCipherSuites() does not contain "SSLv3", or.. a
test server otherwise proves it.
The testing part might be a bugger, as not all servers allow you to
control this (MockWebserver can). Regardless, there are many ways to
assert this.
Bottom line, I'd hesitate to offer any patch (particularly shotgun
ideas) before a test proves is is correct, and this thread absolutely
is hijacking the release as the scope is all jclouds versions.
-A
http://docs.oracle.com/javase/6/docs/api/javax/net/ssl/SSLSocket.html#getEnabledCipherSuites()
On Tue, Oct 21, 2014 at 7:56 AM, Adrian Cole <ad...@gmail.com> wrote:
> For those who like code...
>
> SSLContext sc = SSLContext.getInstance("TLS");
> sc.init(null, null, null);
> HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
>
> Look ma.. no guice.. no jclouds for that matter either.
>
> We shouldn't block the release; we've already squandered enough time
> on this one.
> -A
>
> http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/HttpsURLConnection.html#setDefaultSSLSocketFactory(javax.net.ssl.SSLSocketFactory)http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/HttpsURLConnection.html#setDefaultSSLSocketFactory(javax.net.ssl.SSLSocketFactory)
>
> On Mon, Oct 20, 2014 at 5:11 PM, Adrian Cole <ad...@gmail.com> wrote:
>> PS as I certainly got into the weeds, just there.. will clarify,
>> especially as gaul raised valid points.
>>
>> 1. I think the proposed fix is distracting, so wouldn't hold back a
>> release on that.
>> 2. I don't think it would harm many, if any, if we told folks how to
>> change jclouds to not use ssl v3
>> 3. I suggested a patch, because I think that we shouldn't hold users
>> who care about poodle hostage to 1.8.1
>>
>> ...but..
>>
>> I think this should also work
>>
>> HttpsURLConnection.setDefaultSSLSocketFactory(patchedOne)
>>
>> This is probably a better quick fix, since it involves no guice. Not
>> involving guice means we can reorganize a better long-term solution,
>> and hopefully make test cases to prove it for all http drivers.
>>
>> -A
>>
>> On Mon, Oct 20, 2014 at 4:57 PM, Adrian Cole <ad...@gmail.com> wrote:
>>> Right. So, I think the safest way is to provide the information to
>>> those who wish to patch for poodle. This limits scope of the change to
>>> those interested in it, and also fixes those who aren't ready to
>>> switch to 1.8.1
>>>
>>> They would do this.
>>>
>>> contextBuilder.modules(..., new AbstractModule() {
>>> @Override public void configure(){}
>>> @Provides @Singleton Supplier<SSLContext> unpoodled() {
>>> return // favorite thing.
>>> });
>>>
>>> done. Problem answered.. scope limited.
>>>
>>> We then have bought time to think it through a bit. For example, we
>>> may want to restructure how the ssl contexts are passed around, or
>>> address other http clients in a consistent way such that client auth
>>> based apis can still work. (ex. maybe contextBuilder.sslProtocols)
>>>
>>> -A
>>>
>>> ----longer part---
>>>
>>>
>>> Apache hc was written not knowing that the default executor does this.
>>>
>>> @Inject(optional = true)
>>> protected Supplier<SSLContext> sslContextSupplier;
>>>
>>> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java#L80
>>>
>>> It started doing that because of FCGP.. Only other api that does
>>> something similar is azurecompute. These two modify the default ssl
>>> context to allow client auth and if they can't, bad things happen. It
>>> interestingly becomes the case that we need to modify the default ssl
>>> context as a part of addressing poodle!
>>>
>>> So, considering most folks don't install apachehc, we could defer
>>> addressing that, or otherwise hardcoding it. We could suggest that the
>>> most immediate fix (one that won't break any non-labs stuff), is to
>>> make this patch.
>>>
>>> contextBuilder.modules(..., new AbstractModule() {
>>> @Override public void configure(){}
>>> @Provides @Singleton Supplier<SSLContext> unpoodled() {
>>> return // favorite thing.
>>> });
>>>
>>> This will work for those who must change it, regardless of 1.8.1 or
>>> not, since all asf releases have the optionally injected ssl context
>>> supplier.
>>>
>>> Also, this limits risk only to those who install it. Remember that
>>> private cloud may not even run TLS stacks, even if it "should". It
>>> would totally suck to break folks running tests, etc. if we have a
>>> choice. Now, since we do know which clouds are "providers" we could
>>> auto-fix all public cloud services. Just saying that it isn't the case
>>> that every enterprise will patch all internal servers.
>>>
>>> WRT "untrusted" I think it confuses things to patch poodle, yet trust
>>> all certs :) That's why I suggest rolling back that part.
>>>
>>> On Mon, Oct 20, 2014 at 10:27 AM, Andrew Phillips <ap...@qrmedia.com> wrote:
>>>>> Don't mess with the untrusted one. Fix apachehc later.
>>>>
>>>>
>>>> To be clear: by this, you mean *don't* go for the change in SSLModule in
>>>> [1]? As far as I understand the code, that is also the "untrusted" context
>>>> used in ApacheHC - the one that's being modified in [1] is in case the user
>>>> is *not* looking to trust all certs [2].
>>>>
>>>> ap
>>>>
>>>> [1] https://github.com/jclouds/jclouds/pull/575/files
>>>> [2]
>>>> https://github.com/jclouds/jclouds/blob/enforce-tls/drivers/apachehc/src/main/java/org/jclouds/http/apachehc/config/ApacheHCHttpCommandExecutorServiceModule.java#L114-L119
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Adrian Cole <ad...@gmail.com>.
> Did you actually test this? This also does not work in my testing. As
> the javadoc says:
> "Sets the default SSLSocketFactory inherited by new instances of this class."
Nope. I didn't test this, hence my suggestion to do test shotgun advice.
> The implication being that if application code explicitly sets the
> socket factory, it will override the default.
If the application is overriding this and they are concerned about
POODLE, they should change that.
> This is exactly what
> JavaHttpCommandExecutorService does:
>
> core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java:
> sslCon.setSSLSocketFactory(sslContextSupplier.get().getSocketFactory());
You are wrong here. this is guarded by an if statement
https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java#L205
This won't be invoked unless you are working on fgcp or azurecompute
(labs), or you have a custom guice module.
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Diwaker Gupta <di...@maginatics.com>.
On Tue, Oct 21, 2014 at 7:56 AM, Adrian Cole <ad...@gmail.com> wrote:
> For those who like code...
>
> SSLContext sc = SSLContext.getInstance("TLS");
As I've mentioned elsewhere, this does _not_ work as expected. The
javadoc[1] is intentionally ambiguous:
"Supports some version of TLS; may support other versions"
You must explicitly specify the set of supported protocols (or somehow
exclude SSLv3)
> HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
Did you actually test this? This also does not work in my testing. As
the javadoc says:
"Sets the default SSLSocketFactory inherited by new instances of this class."
The implication being that if application code explicitly sets the
socket factory, it will override the default. This is exactly what
JavaHttpCommandExecutorService does:
core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java:
sslCon.setSSLSocketFactory(sslContextSupplier.get().getSocketFactory());
core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java:
sslCon.setSSLSocketFactory(untrustedSSLContextProvider.get().getSocketFactory());
[1] http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#SSLContext
[2] http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/HttpsURLConnection.html#setDefaultSSLSocketFactory(javax.net.ssl.SSLSocketFactory)
> On Mon, Oct 20, 2014 at 5:11 PM, Adrian Cole <ad...@gmail.com> wrote:
>> PS as I certainly got into the weeds, just there.. will clarify,
>> especially as gaul raised valid points.
>>
>> 1. I think the proposed fix is distracting, so wouldn't hold back a
>> release on that.
>> 2. I don't think it would harm many, if any, if we told folks how to
>> change jclouds to not use ssl v3
>> 3. I suggested a patch, because I think that we shouldn't hold users
>> who care about poodle hostage to 1.8.1
>>
>> ...but..
>>
>> I think this should also work
>>
>> HttpsURLConnection.setDefaultSSLSocketFactory(patchedOne)
>>
>> This is probably a better quick fix, since it involves no guice. Not
>> involving guice means we can reorganize a better long-term solution,
>> and hopefully make test cases to prove it for all http drivers.
>>
>> -A
>>
>> On Mon, Oct 20, 2014 at 4:57 PM, Adrian Cole <ad...@gmail.com> wrote:
>>> Right. So, I think the safest way is to provide the information to
>>> those who wish to patch for poodle. This limits scope of the change to
>>> those interested in it, and also fixes those who aren't ready to
>>> switch to 1.8.1
>>>
>>> They would do this.
>>>
>>> contextBuilder.modules(..., new AbstractModule() {
>>> @Override public void configure(){}
>>> @Provides @Singleton Supplier<SSLContext> unpoodled() {
>>> return // favorite thing.
>>> });
>>>
>>> done. Problem answered.. scope limited.
>>>
>>> We then have bought time to think it through a bit. For example, we
>>> may want to restructure how the ssl contexts are passed around, or
>>> address other http clients in a consistent way such that client auth
>>> based apis can still work. (ex. maybe contextBuilder.sslProtocols)
>>>
>>> -A
>>>
>>> ----longer part---
>>>
>>>
>>> Apache hc was written not knowing that the default executor does this.
>>>
>>> @Inject(optional = true)
>>> protected Supplier<SSLContext> sslContextSupplier;
>>>
>>> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java#L80
>>>
>>> It started doing that because of FCGP.. Only other api that does
>>> something similar is azurecompute. These two modify the default ssl
>>> context to allow client auth and if they can't, bad things happen. It
>>> interestingly becomes the case that we need to modify the default ssl
>>> context as a part of addressing poodle!
>>>
>>> So, considering most folks don't install apachehc, we could defer
>>> addressing that, or otherwise hardcoding it. We could suggest that the
>>> most immediate fix (one that won't break any non-labs stuff), is to
>>> make this patch.
>>>
>>> contextBuilder.modules(..., new AbstractModule() {
>>> @Override public void configure(){}
>>> @Provides @Singleton Supplier<SSLContext> unpoodled() {
>>> return // favorite thing.
>>> });
>>>
>>> This will work for those who must change it, regardless of 1.8.1 or
>>> not, since all asf releases have the optionally injected ssl context
>>> supplier.
>>>
>>> Also, this limits risk only to those who install it. Remember that
>>> private cloud may not even run TLS stacks, even if it "should". It
>>> would totally suck to break folks running tests, etc. if we have a
>>> choice. Now, since we do know which clouds are "providers" we could
>>> auto-fix all public cloud services. Just saying that it isn't the case
>>> that every enterprise will patch all internal servers.
>>>
>>> WRT "untrusted" I think it confuses things to patch poodle, yet trust
>>> all certs :) That's why I suggest rolling back that part.
>>>
>>> On Mon, Oct 20, 2014 at 10:27 AM, Andrew Phillips <ap...@qrmedia.com> wrote:
>>>>> Don't mess with the untrusted one. Fix apachehc later.
>>>>
>>>>
>>>> To be clear: by this, you mean *don't* go for the change in SSLModule in
>>>> [1]? As far as I understand the code, that is also the "untrusted" context
>>>> used in ApacheHC - the one that's being modified in [1] is in case the user
>>>> is *not* looking to trust all certs [2].
>>>>
>>>> ap
>>>>
>>>> [1] https://github.com/jclouds/jclouds/pull/575/files
>>>> [2]
>>>> https://github.com/jclouds/jclouds/blob/enforce-tls/drivers/apachehc/src/main/java/org/jclouds/http/apachehc/config/ApacheHCHttpCommandExecutorServiceModule.java#L114-L119
--
http://maginatics.com
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Adrian Cole <ad...@gmail.com>.
For those who like code...
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(null, null, null);
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
Look ma.. no guice.. no jclouds for that matter either.
We shouldn't block the release; we've already squandered enough time
on this one.
-A
http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/HttpsURLConnection.html#setDefaultSSLSocketFactory(javax.net.ssl.SSLSocketFactory)http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/HttpsURLConnection.html#setDefaultSSLSocketFactory(javax.net.ssl.SSLSocketFactory)
On Mon, Oct 20, 2014 at 5:11 PM, Adrian Cole <ad...@gmail.com> wrote:
> PS as I certainly got into the weeds, just there.. will clarify,
> especially as gaul raised valid points.
>
> 1. I think the proposed fix is distracting, so wouldn't hold back a
> release on that.
> 2. I don't think it would harm many, if any, if we told folks how to
> change jclouds to not use ssl v3
> 3. I suggested a patch, because I think that we shouldn't hold users
> who care about poodle hostage to 1.8.1
>
> ...but..
>
> I think this should also work
>
> HttpsURLConnection.setDefaultSSLSocketFactory(patchedOne)
>
> This is probably a better quick fix, since it involves no guice. Not
> involving guice means we can reorganize a better long-term solution,
> and hopefully make test cases to prove it for all http drivers.
>
> -A
>
> On Mon, Oct 20, 2014 at 4:57 PM, Adrian Cole <ad...@gmail.com> wrote:
>> Right. So, I think the safest way is to provide the information to
>> those who wish to patch for poodle. This limits scope of the change to
>> those interested in it, and also fixes those who aren't ready to
>> switch to 1.8.1
>>
>> They would do this.
>>
>> contextBuilder.modules(..., new AbstractModule() {
>> @Override public void configure(){}
>> @Provides @Singleton Supplier<SSLContext> unpoodled() {
>> return // favorite thing.
>> });
>>
>> done. Problem answered.. scope limited.
>>
>> We then have bought time to think it through a bit. For example, we
>> may want to restructure how the ssl contexts are passed around, or
>> address other http clients in a consistent way such that client auth
>> based apis can still work. (ex. maybe contextBuilder.sslProtocols)
>>
>> -A
>>
>> ----longer part---
>>
>>
>> Apache hc was written not knowing that the default executor does this.
>>
>> @Inject(optional = true)
>> protected Supplier<SSLContext> sslContextSupplier;
>>
>> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java#L80
>>
>> It started doing that because of FCGP.. Only other api that does
>> something similar is azurecompute. These two modify the default ssl
>> context to allow client auth and if they can't, bad things happen. It
>> interestingly becomes the case that we need to modify the default ssl
>> context as a part of addressing poodle!
>>
>> So, considering most folks don't install apachehc, we could defer
>> addressing that, or otherwise hardcoding it. We could suggest that the
>> most immediate fix (one that won't break any non-labs stuff), is to
>> make this patch.
>>
>> contextBuilder.modules(..., new AbstractModule() {
>> @Override public void configure(){}
>> @Provides @Singleton Supplier<SSLContext> unpoodled() {
>> return // favorite thing.
>> });
>>
>> This will work for those who must change it, regardless of 1.8.1 or
>> not, since all asf releases have the optionally injected ssl context
>> supplier.
>>
>> Also, this limits risk only to those who install it. Remember that
>> private cloud may not even run TLS stacks, even if it "should". It
>> would totally suck to break folks running tests, etc. if we have a
>> choice. Now, since we do know which clouds are "providers" we could
>> auto-fix all public cloud services. Just saying that it isn't the case
>> that every enterprise will patch all internal servers.
>>
>> WRT "untrusted" I think it confuses things to patch poodle, yet trust
>> all certs :) That's why I suggest rolling back that part.
>>
>> On Mon, Oct 20, 2014 at 10:27 AM, Andrew Phillips <ap...@qrmedia.com> wrote:
>>>> Don't mess with the untrusted one. Fix apachehc later.
>>>
>>>
>>> To be clear: by this, you mean *don't* go for the change in SSLModule in
>>> [1]? As far as I understand the code, that is also the "untrusted" context
>>> used in ApacheHC - the one that's being modified in [1] is in case the user
>>> is *not* looking to trust all certs [2].
>>>
>>> ap
>>>
>>> [1] https://github.com/jclouds/jclouds/pull/575/files
>>> [2]
>>> https://github.com/jclouds/jclouds/blob/enforce-tls/drivers/apachehc/src/main/java/org/jclouds/http/apachehc/config/ApacheHCHttpCommandExecutorServiceModule.java#L114-L119
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Adrian Cole <ad...@gmail.com>.
PS as I certainly got into the weeds, just there.. will clarify,
especially as gaul raised valid points.
1. I think the proposed fix is distracting, so wouldn't hold back a
release on that.
2. I don't think it would harm many, if any, if we told folks how to
change jclouds to not use ssl v3
3. I suggested a patch, because I think that we shouldn't hold users
who care about poodle hostage to 1.8.1
...but..
I think this should also work
HttpsURLConnection.setDefaultSSLSocketFactory(patchedOne)
This is probably a better quick fix, since it involves no guice. Not
involving guice means we can reorganize a better long-term solution,
and hopefully make test cases to prove it for all http drivers.
-A
On Mon, Oct 20, 2014 at 4:57 PM, Adrian Cole <ad...@gmail.com> wrote:
> Right. So, I think the safest way is to provide the information to
> those who wish to patch for poodle. This limits scope of the change to
> those interested in it, and also fixes those who aren't ready to
> switch to 1.8.1
>
> They would do this.
>
> contextBuilder.modules(..., new AbstractModule() {
> @Override public void configure(){}
> @Provides @Singleton Supplier<SSLContext> unpoodled() {
> return // favorite thing.
> });
>
> done. Problem answered.. scope limited.
>
> We then have bought time to think it through a bit. For example, we
> may want to restructure how the ssl contexts are passed around, or
> address other http clients in a consistent way such that client auth
> based apis can still work. (ex. maybe contextBuilder.sslProtocols)
>
> -A
>
> ----longer part---
>
>
> Apache hc was written not knowing that the default executor does this.
>
> @Inject(optional = true)
> protected Supplier<SSLContext> sslContextSupplier;
>
> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java#L80
>
> It started doing that because of FCGP.. Only other api that does
> something similar is azurecompute. These two modify the default ssl
> context to allow client auth and if they can't, bad things happen. It
> interestingly becomes the case that we need to modify the default ssl
> context as a part of addressing poodle!
>
> So, considering most folks don't install apachehc, we could defer
> addressing that, or otherwise hardcoding it. We could suggest that the
> most immediate fix (one that won't break any non-labs stuff), is to
> make this patch.
>
> contextBuilder.modules(..., new AbstractModule() {
> @Override public void configure(){}
> @Provides @Singleton Supplier<SSLContext> unpoodled() {
> return // favorite thing.
> });
>
> This will work for those who must change it, regardless of 1.8.1 or
> not, since all asf releases have the optionally injected ssl context
> supplier.
>
> Also, this limits risk only to those who install it. Remember that
> private cloud may not even run TLS stacks, even if it "should". It
> would totally suck to break folks running tests, etc. if we have a
> choice. Now, since we do know which clouds are "providers" we could
> auto-fix all public cloud services. Just saying that it isn't the case
> that every enterprise will patch all internal servers.
>
> WRT "untrusted" I think it confuses things to patch poodle, yet trust
> all certs :) That's why I suggest rolling back that part.
>
> On Mon, Oct 20, 2014 at 10:27 AM, Andrew Phillips <ap...@qrmedia.com> wrote:
>>> Don't mess with the untrusted one. Fix apachehc later.
>>
>>
>> To be clear: by this, you mean *don't* go for the change in SSLModule in
>> [1]? As far as I understand the code, that is also the "untrusted" context
>> used in ApacheHC - the one that's being modified in [1] is in case the user
>> is *not* looking to trust all certs [2].
>>
>> ap
>>
>> [1] https://github.com/jclouds/jclouds/pull/575/files
>> [2]
>> https://github.com/jclouds/jclouds/blob/enforce-tls/drivers/apachehc/src/main/java/org/jclouds/http/apachehc/config/ApacheHCHttpCommandExecutorServiceModule.java#L114-L119
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> In this case, the static method on HttpUrlConnection approach may be more
> appropriate. Basically we can point to documentation about it and it
> requires no special knowledge and can be plopped in at bootstrap code.
@Andrew G: would documenting this and/or the module fix address your concerns?
Given where we are, my suggestion is as follows: if we can't resolve
-1 votes by the end of the day, I'll cancel this release and work
towards a 1.8.1-rc2.
In this case, I would like to urge all those who are uncomfortable
with releasing rc1 at this point to improve the current proposed fix,
since from the discussion it is clear it is currently not a state we
would like to include in 1.8.1.
If we can resolve the -1s, I would obviously still like to work on
fixing JCLOUDS-753 as quickly as reasonably possible. Hopefully, with
the release behind us we will a little bit more time for that.
Regards
ap
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Adrian Cole <ad...@gmail.com>.
> I understand Diwaker's comment [1] in the JIRA issue that configuring
your own module is not exactly "trivial", but seeing as we seem to agree at
this point that this issue does *not* pose an immediate security risk to
jclouds users generally, I feel that we can get away with the above
proposal.
In this case, the static method on HttpUrlConnection approach may be more
appropriate. Basically we can point to documentation about it and it
requires no special knowledge and can be plopped in at bootstrap code.
> @Adrian: TL;DR: if "untrusted" here means "trust all certs", I'm not sure
we should allow it to be insecure in all kinds of *other* ways, too. But
since we are looking for a different fix in any case, we'll probably end up
discussing this in more detail after 1.8.1 anyway ;-)
Honestly, I get what you are saying. Untrusted was made so that folks using
test proxies and self-signed certs can work. I hope it isn't used over the
internet, as that is worse than poodle. If you wish to be thorough, I would
make sure it is tested. There's a cost to that, and documentation and
maintenance.
>
> [1]
https://issues.apache.org/jira/browse/JCLOUDS-753?focusedCommentId=14174271&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14174271
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> They would do this.
>
> contextBuilder.modules(..., new AbstractModule() {
> @Override public void configure(){}
> @Provides @Singleton Supplier<SSLContext> unpoodled() {
> return // favorite thing.
> });
@gaul: would describing this in the release notes make you reconsider
your vote? I also of course want to fix this, but from the discussion
it is clear we haven't found the right approach yet.
If we are going to apply band-aids for now, I would prefer to document
a band-aid that does not do something we're not totally happy with,
also applies to non-1.8.1 users and gives the users more ability to
make their own choices.
I understand Diwaker's comment [1] in the JIRA issue that configuring
your own module is not exactly "trivial", but seeing as we seem to
agree at this point that this issue does *not* pose an immediate
security risk to jclouds users generally, I feel that we can get away
with the above proposal.
> WRT "untrusted" I think it confuses things to patch poodle, yet trust
> all certs :) That's why I suggest rolling back that part.
@Adrian: TL;DR: if "untrusted" here means "trust all certs", I'm not
sure we should allow it to be insecure in all kinds of *other* ways,
too. But since we are looking for a different fix in any case, we'll
probably end up discussing this in more detail after 1.8.1 anyway ;-)
-- longer version --
Thanks for explaining that. I see what you mean about the perceived
asymmetry of trying to patch this in an "untrusted" context. I may be
interpreting the word incorrectly - my understanding of "untrusted"
here and when referring to SSL connections generally is specifically
"trust all certificates".
This is certainly insecure in many ways, but I don't think it means we
should allow this to be insecure in all kinds of other ways, too - or,
if that is so, we should call it "insecure" rather than "untrusted".
Depending on how the vote ends up going, it seems to me that we will
be looking for a different solution here in any case, so we will
probably see this discussion come around then.
Regards
ap
[1]
https://issues.apache.org/jira/browse/JCLOUDS-753?focusedCommentId=14174271&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14174271
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Adrian Cole <ad...@gmail.com>.
Right. So, I think the safest way is to provide the information to
those who wish to patch for poodle. This limits scope of the change to
those interested in it, and also fixes those who aren't ready to
switch to 1.8.1
They would do this.
contextBuilder.modules(..., new AbstractModule() {
@Override public void configure(){}
@Provides @Singleton Supplier<SSLContext> unpoodled() {
return // favorite thing.
});
done. Problem answered.. scope limited.
We then have bought time to think it through a bit. For example, we
may want to restructure how the ssl contexts are passed around, or
address other http clients in a consistent way such that client auth
based apis can still work. (ex. maybe contextBuilder.sslProtocols)
-A
----longer part---
Apache hc was written not knowing that the default executor does this.
@Inject(optional = true)
protected Supplier<SSLContext> sslContextSupplier;
https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java#L80
It started doing that because of FCGP.. Only other api that does
something similar is azurecompute. These two modify the default ssl
context to allow client auth and if they can't, bad things happen. It
interestingly becomes the case that we need to modify the default ssl
context as a part of addressing poodle!
So, considering most folks don't install apachehc, we could defer
addressing that, or otherwise hardcoding it. We could suggest that the
most immediate fix (one that won't break any non-labs stuff), is to
make this patch.
contextBuilder.modules(..., new AbstractModule() {
@Override public void configure(){}
@Provides @Singleton Supplier<SSLContext> unpoodled() {
return // favorite thing.
});
This will work for those who must change it, regardless of 1.8.1 or
not, since all asf releases have the optionally injected ssl context
supplier.
Also, this limits risk only to those who install it. Remember that
private cloud may not even run TLS stacks, even if it "should". It
would totally suck to break folks running tests, etc. if we have a
choice. Now, since we do know which clouds are "providers" we could
auto-fix all public cloud services. Just saying that it isn't the case
that every enterprise will patch all internal servers.
WRT "untrusted" I think it confuses things to patch poodle, yet trust
all certs :) That's why I suggest rolling back that part.
On Mon, Oct 20, 2014 at 10:27 AM, Andrew Phillips <ap...@qrmedia.com> wrote:
>> Don't mess with the untrusted one. Fix apachehc later.
>
>
> To be clear: by this, you mean *don't* go for the change in SSLModule in
> [1]? As far as I understand the code, that is also the "untrusted" context
> used in ApacheHC - the one that's being modified in [1] is in case the user
> is *not* looking to trust all certs [2].
>
> ap
>
> [1] https://github.com/jclouds/jclouds/pull/575/files
> [2]
> https://github.com/jclouds/jclouds/blob/enforce-tls/drivers/apachehc/src/main/java/org/jclouds/http/apachehc/config/ApacheHCHttpCommandExecutorServiceModule.java#L114-L119
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Don't mess with the untrusted one. Fix apachehc later.
To be clear: by this, you mean *don't* go for the change in SSLModule
in [1]? As far as I understand the code, that is also the "untrusted"
context used in ApacheHC - the one that's being modified in [1] is in
case the user is *not* looking to trust all certs [2].
ap
[1] https://github.com/jclouds/jclouds/pull/575/files
[2]
https://github.com/jclouds/jclouds/blob/enforce-tls/drivers/apachehc/src/main/java/org/jclouds/http/apachehc/config/ApacheHCHttpCommandExecutorServiceModule.java#L114-L119
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Niraj Tolia <nt...@maginatics.com>.
On Thu, Oct 16, 2014 at 10:04 PM, Chris Custine <ch...@gmail.com> wrote:
>
> On October 16, 2014 at 10:49:33 PM, Niraj Tolia (ntolia@maginatics.com(mailto:ntolia@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 (aphillips@qrmedia.com(mailto:aphillips@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
>> >
>
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Chris Custine <ch...@gmail.com>.
I should have added that I am not arguing against patching and releasing a new RC. It will certainly help people to have warm fuzzies, but I can't see any way for it to be used against a codebase like jclouds. Hopefully someone can point out if I am wrong about that.
--
Chris Custine
On October 16, 2014 at 11:04:22 PM, Chris Custine (chris.custine@gmail.com(mailto:chris.custine@gmail.com)) wrote:
>
> On October 16, 2014 at 10:49:33 PM, Niraj Tolia (ntolia@maginatics.com(mailto:ntolia@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. :-)
>
> 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 (aphillips@qrmedia.com(mailto:aphillips@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
> > >
>
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Chris Custine <ch...@gmail.com>.
On October 16, 2014 at 10:49:33 PM, Niraj Tolia (ntolia@maginatics.com(mailto:ntolia@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. :-)
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 (aphillips@qrmedia.com(mailto:aphillips@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
> >
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Niraj Tolia <nt...@maginatics.com>.
On Thu, Oct 16, 2014 at 9:43 PM, Chris Custine <ch...@gmail.com> 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:
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.
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 (aphillips@qrmedia.com(mailto:aphillips@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
>
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Chris Custine <ch...@gmail.com>.
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.
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 (aphillips@qrmedia.com(mailto:aphillips@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
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> 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
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Andrew Gaul <ga...@apache.org>.
On Fri, Oct 17, 2014 at 12:45:15AM +0200, Andrew Phillips wrote:
> >issues, mostly with signed URLs and request limiting. The POODLE issue
> >described in JCLOUDS-753 concerns me although I do not have time this
> >week to investigate its severity.
>
> Anyone else have thoughts on this? Diwaker's comments in the JIRA
> issue suggest that we may want to consider this as a blocker.
>
> I unfortunately don't have any time to test this immediately, but I
> think it would be very helpful to know whether it is possible
>
> 1. to use a different HTTP driver or
> 2. to supply a config module to the ContextBuilder to appropriately
> override the SSL config
>
> to mitigate this.
>
> Does anyone have some cycles to look into this?
I prefer to exercise an abundance of caution and extend the vote until
we understand the issue. Otherwise we may need to immediately run
another release. I can look at this over the weekend if no one else
volunteers.
--
Andrew Gaul
http://gaul.org/
Re: [DISCUSS] Release Apache jclouds 1.8.1 RC1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> issues, mostly with signed URLs and request limiting. The POODLE issue
> described in JCLOUDS-753 concerns me although I do not have time this
> week to investigate its severity.
Anyone else have thoughts on this? Diwaker's comments in the JIRA
issue suggest that we may want to consider this as a blocker.
I unfortunately don't have any time to test this immediately, but I
think it would be very helpful to know whether it is possible
1. to use a different HTTP driver or
2. to supply a config module to the ContextBuilder to appropriately
override the SSL config
to mitigate this.
Does anyone have some cycles to look into this?
Regards
ap
Re: [VOTE] Release Apache jclouds 1.8.1 RC1
Posted by Andrew Phillips <an...@apache.org>.
=======================================================================
Apache ID: andrewp
-----------------------------------------------------------------------
[X] +1 Release.
[ ] -1 Don't release (see notes).
-----------------------------------------------------------------------
Checklist (all items optional, mark only those personally verified):
[X] Checksums and PGP signatures are valid.
[ ] Expanded source archive matches contents of RC tag.
[X] Expanded source archive builds and passes tests.
[X] LICENSE is present and correct.
[X] NOTICE is present and correct, including copyright date.
[X] All files have license headers where appropriate.
[X] All dependencies have compatible licenses.
[X] No compiled archives bundled in source archive.
[ ] I follow this project's commits list.
-----------------------------------------------------------------------
Notes:
* Based on my understanding of the
* Ran 'mvn clean install -Dmaven.javadoc.skip=true', which includes
the RAT plugin execution.
* Checked for compiled archives by searching for ".jar", ".bin",
".zip" and ".tar.gz" in the expanded source archives
* Built the blobstore-basics example for jclouds-examples (required some
changes, since the examples are not compatible with 1.8.1) and ran it
successfully against cloudonestorage
Thanks to everyone who's helped with the live testing and
investigating the potential impact of POODLE.
ap
Re: [VOTE] Release Apache jclouds 1.8.1 RC1
Posted by Andrew Gaul <ga...@apache.org>.
+1, binding. I ran the verify script and integration tests against all
of the blobstores with JDK 1.7. The former has some HashMap ordering
issues with JDK 1.8 and chef. The latter has a handful of transient
issues, mostly with signed URLs and request limiting. The POODLE issue
described in JCLOUDS-753 concerns me although I do not have time this
week to investigate its severity.
On Sat, Oct 11, 2014 at 06:15:39PM +0200, Andrew Phillips wrote:
> Hello,
>
> This is the first release candidate for Apache jclouds 1.8.1.
>
> Please use the separate [DISCUSS] thread for anything but votes.
>
> It fixes the following issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12327548&styleName=Html&projectId=12314430
>
> *** Please download, test and vote by Thursday, October 16th, 09:00
> PDT / 12:00 EDT / 18:00 CET.
>
> Note that we are voting upon the source (tag), binaries are provided
> for convenience.
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/jclouds/1.8.1-rc1/
>
> Maven staging repos:
> https://repository.apache.org/content/repositories/orgapachejclouds-1020/
> (jclouds, jclouds-labs, jclouds-labs-aws, jclouds-labs-google,
> jclouds-labs-openstack)
> https://repository.apache.org/content/repositories/orgapachejclouds-1021/
> (jclouds-chef, jclouds-karaf, jclouds-cli)
>
> Note: upload completed from different IP addresses, hence the two repos.
>
> The tags to be voted upon:
> - jclouds - https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=tag;h=0ce7270381cb554052ac1ea99baf9464000a3754
> (SHA-1: d17a59097377e2667c854b8238c2cce818024f30)
> - jclouds-labs - https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;a=tag;h=5bde375e996d521eb57adc9f346b679d7e03efa2
> (SHA-1: 1152a38a50cb550b65336204b168b4f696e59a75)
> - jclouds-labs-aws - https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-aws.git;a=tag;h=28272367bc4c06aaf5d60ac5d276877d2a37679b
> (SHA-1: 7cffc5dc3b54322a319aa2b3c265564e0298b8d4)
> - jclouds-labs-google - https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;a=tag;h=eb6117508a0ebe03dd97306650cf81ac7f26500d
> (SHA-1: cf58f92038e6b6ccfac09db581d5d24c885f211c)
> - jclouds-labs-openstack - https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-openstack.git;a=tag;h=d244a21b9036acb8f6a1cf6d9e383abc5f86845b
> (SHA-1: 26309321436df711c9a0914e46bb1205e9fc7378)
> - jclouds-chef - https://git-wip-us.apache.org/repos/asf?p=jclouds-chef.git;a=tag;h=b1081301e18a88b4f4ea647558095604416bff42
> (SHA-1: 22be869dd87bd21f2a7fbe04dfa547f37012ffa3)
> - jclouds-karaf - https://git-wip-us.apache.org/repos/asf?p=jclouds-karaf.git;a=tag;h=8678a5a592614853ed8220f42ce7aac7d0c462b6
> (SHA-1: d7bfecac7e5787ba93b4cee81bcd77596fba14d2)
> - jclouds-cli - https://git-wip-us.apache.org/repos/asf?p=jclouds-cli.git;a=tag;h=368c29fc06bd24f581999e1385c10337c507528b
> (SHA-1: a5c2571e405fd559641fe7ba6980f4618808fa37)
>
> jclouds KEYS file containing PGP keys we use to sign the release:
> http://www.apache.org/dist/jclouds/KEYS
>
> [ ] +1
> [ ] 0 (explain why)
> [ ] -1 (explain why)
>
> Regards
>
> ap
--
Andrew Gaul
http://gaul.org/
Re: [VOTE] Release Apache jclouds 1.8.1 RC1
Posted by Chris Custine <ch...@gmail.com>.
+1
--
Chris Custine
On October 12, 2014 at 3:59:17 PM, Andrew Phillips (aphillips@qrmedia.com(mailto:aphillips@qrmedia.com)) wrote:
> Hello,
>
> This is the first release candidate for Apache jclouds 1.8.1.
>
> Please use the separate [DISCUSS] thread for anything but votes.
>
> It fixes the following issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12327548&styleName=Html&projectId=12314430
>
> *** Please download, test and vote by Thursday, October 16th, 09:00
> PDT / 12:00 EDT / 18:00 CET.
>
> Note that we are voting upon the source (tag), binaries are provided
> for convenience.
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/jclouds/1.8.1-rc1/
>
> Maven staging repos:
> https://repository.apache.org/content/repositories/orgapachejclouds-1020/
> (jclouds, jclouds-labs, jclouds-labs-aws, jclouds-labs-google,
> jclouds-labs-openstack)
> https://repository.apache.org/content/repositories/orgapachejclouds-1021/
> (jclouds-chef, jclouds-karaf, jclouds-cli)
>
> Note: upload completed from different IP addresses, hence the two repos.
>
> The tags to be voted upon:
> - jclouds -
> https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=tag;h=0ce7270381cb554052ac1ea99baf9464000a3754 (SHA-1:
> d17a59097377e2667c854b8238c2cce818024f30)
> - jclouds-labs -
> https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;a=tag;h=5bde375e996d521eb57adc9f346b679d7e03efa2 (SHA-1:
> 1152a38a50cb550b65336204b168b4f696e59a75)
> - jclouds-labs-aws -
> https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-aws.git;a=tag;h=28272367bc4c06aaf5d60ac5d276877d2a37679b (SHA-1:
> 7cffc5dc3b54322a319aa2b3c265564e0298b8d4)
> - jclouds-labs-google -
> https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;a=tag;h=eb6117508a0ebe03dd97306650cf81ac7f26500d (SHA-1:
> cf58f92038e6b6ccfac09db581d5d24c885f211c)
> - jclouds-labs-openstack -
> https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-openstack.git;a=tag;h=d244a21b9036acb8f6a1cf6d9e383abc5f86845b (SHA-1:
> 26309321436df711c9a0914e46bb1205e9fc7378)
> - jclouds-chef -
> https://git-wip-us.apache.org/repos/asf?p=jclouds-chef.git;a=tag;h=b1081301e18a88b4f4ea647558095604416bff42 (SHA-1:
> 22be869dd87bd21f2a7fbe04dfa547f37012ffa3)
> - jclouds-karaf -
> https://git-wip-us.apache.org/repos/asf?p=jclouds-karaf.git;a=tag;h=8678a5a592614853ed8220f42ce7aac7d0c462b6 (SHA-1:
> d7bfecac7e5787ba93b4cee81bcd77596fba14d2)
> - jclouds-cli -
> https://git-wip-us.apache.org/repos/asf?p=jclouds-cli.git;a=tag;h=368c29fc06bd24f581999e1385c10337c507528b (SHA-1:
> a5c2571e405fd559641fe7ba6980f4618808fa37)
>
> jclouds KEYS file containing PGP keys we use to sign the release:
> http://www.apache.org/dist/jclouds/KEYS
>
> [ ] +1
> [ ] 0 (explain why)
> [ ] -1 (explain why)
>
> Regards
>
> ap
Re: [VOTE] Release Apache jclouds 1.8.1 RC1
Posted by Everett Toews <ev...@RACKSPACE.COM>.
+1 binding
* Ran the verification script
* Ran the Rackspace smoke tests
Everett
On Oct 11, 2014, at 11:15 AM, Andrew Phillips <ap...@qrmedia.com> wrote:
> Hello,
>
> This is the first release candidate for Apache jclouds 1.8.1.
>
> Please use the separate [DISCUSS] thread for anything but votes.
>
> It fixes the following issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12327548&styleName=Html&projectId=12314430
>
> *** Please download, test and vote by Thursday, October 16th, 09:00 PDT / 12:00 EDT / 18:00 CET.
>
> Note that we are voting upon the source (tag), binaries are provided for convenience.
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/jclouds/1.8.1-rc1/
>
> Maven staging repos:
> https://repository.apache.org/content/repositories/orgapachejclouds-1020/ (jclouds, jclouds-labs, jclouds-labs-aws, jclouds-labs-google, jclouds-labs-openstack)
> https://repository.apache.org/content/repositories/orgapachejclouds-1021/ (jclouds-chef, jclouds-karaf, jclouds-cli)
>
> Note: upload completed from different IP addresses, hence the two repos.
>
> The tags to be voted upon:
> - jclouds - https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=tag;h=0ce7270381cb554052ac1ea99baf9464000a3754 (SHA-1: d17a59097377e2667c854b8238c2cce818024f30)
> - jclouds-labs - https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;a=tag;h=5bde375e996d521eb57adc9f346b679d7e03efa2 (SHA-1: 1152a38a50cb550b65336204b168b4f696e59a75)
> - jclouds-labs-aws - https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-aws.git;a=tag;h=28272367bc4c06aaf5d60ac5d276877d2a37679b (SHA-1: 7cffc5dc3b54322a319aa2b3c265564e0298b8d4)
> - jclouds-labs-google - https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;a=tag;h=eb6117508a0ebe03dd97306650cf81ac7f26500d (SHA-1: cf58f92038e6b6ccfac09db581d5d24c885f211c)
> - jclouds-labs-openstack - https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-openstack.git;a=tag;h=d244a21b9036acb8f6a1cf6d9e383abc5f86845b (SHA-1: 26309321436df711c9a0914e46bb1205e9fc7378)
> - jclouds-chef - https://git-wip-us.apache.org/repos/asf?p=jclouds-chef.git;a=tag;h=b1081301e18a88b4f4ea647558095604416bff42 (SHA-1: 22be869dd87bd21f2a7fbe04dfa547f37012ffa3)
> - jclouds-karaf - https://git-wip-us.apache.org/repos/asf?p=jclouds-karaf.git;a=tag;h=8678a5a592614853ed8220f42ce7aac7d0c462b6 (SHA-1: d7bfecac7e5787ba93b4cee81bcd77596fba14d2)
> - jclouds-cli - https://git-wip-us.apache.org/repos/asf?p=jclouds-cli.git;a=tag;h=368c29fc06bd24f581999e1385c10337c507528b (SHA-1: a5c2571e405fd559641fe7ba6980f4618808fa37)
>
> jclouds KEYS file containing PGP keys we use to sign the release:
> http://www.apache.org/dist/jclouds/KEYS
>
> [ ] +1
> [ ] 0 (explain why)
> [ ] -1 (explain why)
>
> Regards
>
> ap