Open Stack

After having a brief discussion this morning (NZ time) on the
#python-requests irc, it seems that using the system CA bundle is a "Not a
chance" situation.  They've tried, and found it unmaintainable due to the
vast variations between system layouts (multiple OS, not just multiple
distro).  I can see their point.

Others have mentioned env vars not working particularly well either - which
really leaves a config option and that is something that ops/deployers can
tailor to suit their particular system without either the requests people
nor the OpenStack people having to maintain.

On 16 November 2015 at 04:26, Adam Young <ayoung at redhat.com> wrote:

> On 11/14/2015 03:09 AM, Xav Paice wrote:
>
> Hi,
>
> I'm sure I'm not the only one that likes to use SSL everywhere possible,
> and doesn't like to pay for 'real' ssl certs for dev environments.
> Figuring out how to get requests to allow connection to the self signed
> cert would have paid for a real cert many times over.
>
> When I use an SSL cert with a CA not in the Mozilla bundle, and use
> keystonemiddleware to access Keystone endpoints, the ssl verification
> rightly fails.  It turns out requests doesn't use the system ca cert
> bundle, but has it's own.  It's also got a nice easy config option to set
> which ca cert bundle you want to use -
> http://docs.python-requests.org/en/latest/user/advanced/?highlight=ca_bundle#ssl-cert-verification
>
> How do people feel about having that as a config option set somewhere, so
> we can specify a ca cert in, say, heat.conf, so that we can continue with
> the self signed certs of cheapness without needing to hack up the
> cacert.pem that comes with requests, or find a way to pass in environment
> variables?
>
> Am I barking up the wrong tree here?  How would I go about writing a
> blueprint for this, and for which project?  I guess it's something that
> would need to be added to all the projects in the keystone_authtoken
> section?  Or is there a central place where common configs like this can
> live?
>
>
>
> I would say that the right approach is to add the CA to the system bundle
> for the calling machine.  Requests not using the System defaults is a Bug.
>
> I suspect that the reason that they do this is the unwillingness of the
> Requests developers to have to battle NSS: The Dogtag developers have a
> write up including the steps necessary to get NSS support into Requests.
> http://pki.fedoraproject.org/wiki/Support_NSSDB_in_Python_API
>
>
> On a Fedora system, the python-requests RPM depends on ca-certificates,
> which is updated more frequently than that document indicates;
>
> rpm --query  --list ca-certificates
>
> Shows that it manages the /ec/pki/[ca-trust java tls ] subdirectoies as
> well as /etc/ssl and /usr/share/pki
>
>
> I suspect that Debian based systems do something comparable, although I
> don't have on handy to chack.
>
>
> So, short answer: use the system tools to update.  Lets not make an end
> run around system security.  A config value is another path to Audit.
>
>
>
>
>
>
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151116/1db3b6ba/attachment.html>