I feel conflicted about POODLE and received a variety of feedback about its applicability to jclouds. My non-expert intuition matches Chris Custine's, specifically that exploitation is unlikely in typical jclouds deployments. However, users could have unusual or misconfigured applications and I feel uncomfortable asserting that all possible uses are immune from exploitation.
One standard for whether we should re-spin this release might be: would we definitely or probably include the POODLE fix if someone reported earlier? I believe we would definitely include it and thus should create rc2 including this fix. I apologize for changing my vote on this release but please consider me -1. The suggested fix of disabling SSL 3.0 seems incomplete to me. While there are not likely any cloud services requiring this old protocol, instead should we make the protocols configurable, e.g., specify TLS 1.2-only, 1.1-only, etc.? This would allow future run-time patches to this behavior and provide greater security for paranoid users. This enhancement need not block 1.8.1. On Mon, Oct 20, 2014 at 04:23:37PM +0200, Andrew Phillips wrote: > @Andrew G: did you manage to find some time to have a look at the > POODLE implications for this release? > > @Chris: you mentioned that you were seeing more live test failures > than usual, and were going to investigate before voting. Have you > had a chance to do that? > > Based on this discussion in this thread on POODLE so far, I'm > inclined to not cancel the release since it seems that exploiting > the SSL downgrade would require additional vulnerabilities in > jclouds (see [1]). Of course, we should document this and fix > JCLOUDS-753 asap. > > I'd like to close this vote tomorrow, if at all possible, so if > either of you have any input at this point, that would be much > appreciated. > > Regards > > ap > > [1] http://markmail.org/message/25na5y3gamyacszp -- Andrew Gaul http://gaul.org/
