On 12/09/2013 04:46, Dolph Mathews wrote: > > On Wed, Sep 11, 2013 at 10:25 PM, Jamie Lennox <jlennox at redhat.com > <mailto:jlennox at redhat.com>> wrote: > > With the aim of replacing httplib and cert validation with requests[1] > I've put forward the following review to use the requests library for > auth_token middleware. > > https://review.openstack.org/#/c/34161/ > > This adds 2 new config options. > - The ability to provide CAs to validate https connections against. > - The ability to set insecure to ignore https validation. > > By default request will validate connections against the system CAs by > default. So given that we currently don't verify SSL connections, do we > need to default insecure to true? > > > I vote no; and yes to "secure by default." So do I David > > > Maintaining compatibility should win here as i imagine there are a great > number of auth_token deployments using SSL with invalid/self-signed > certificates that would be broken, but defaulting to insecure just seems > wrong. > > Given that keystone isn't the only project moving away from httplib, how > are other projects handling this? > > > The last time keystoneclient made this same change (thanks Dean!), we > provided no warning: > > https://review.openstack.org/#/c/17624/ > > Which added the --insecure flag to opt back into the old behavior. > > How do we end up with reasonable > defaults? Is there any amount of warning that we could give to change a > default like this - or is this another one of those version 1.0 issues? > > > Jamie > > > > [1] https://bugs.launchpad.net/keystone/+bug/1188189 > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.org > <mailto:OpenStack-dev at lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > > -Dolph > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >