On Wed, Mar 1, 2017 at 3:51 PM, Christian Heimes <christian@python.org> wrote:

On 2017-03-01 15:59, David Cournapeau wrote:
> Hi there,
>
> This is hopefully the right mailing for this question. We are shipping
> our own python interpreter in our product, and following some
> discussions on
> https://mail.python.org/pipermail/python-dev/2017-January/147282.html,
> we understand shipping the certificate from certifi in our python is the
> best approach on Linux/OS X.

Yeah, it's the easiest option for you. I don't necessarily agree it's
the best option.

We are certainly interested in a better option ! Our constraints are:

1. we cannot control where python actually get installed

2. on Linux, we cannot afford to have distribution-specific builds (we use something similar to the manylinux setup)

> Unfortunately, ssl hardcodes at compilation time the default location of
> certificate. I could workaround this at the python level by patching
> ssl.SSLContext.load_default_certs to look as follows:

Small correction: The location of the certs is hard-coded in OpenSSL.
The ssl module simply uses OpenSSL's defaults on non-Windows platforms.

> def load_default_certs(...):
> ....
>
> if sys.platform == "win32":
> ...
> else:
> prefix = os.path.normpath(sys.prefix)
> default_cert = os.path.join(prefix, "ssl", "cert.pem")
> if os.path.isfile(default_cert):
> self.load_verify_locations(default_cert)
> else:
> self.set_default_verify_paths()
>
> While this seems to work, my lack of knowledge in all things related to
> security and ssl in particular makes me worry to patch anything in
> there. Is this a sane approach ? If not, is there a better way ?

You can override the default verify paths already. There is no need to
monkey patch load_default_certs(). You have two options:

1) Create your own custom SSLContext with a custom trust anchor, e.g.
ctx = ssl.create_default_context(cafile='...') and pass the context along.

2) Set SSL_CERT_FILE env var to override OpenSSL's default setting, see
https://docs.python.org/3/library/ssl.html#ssl.get_default_verify_paths

The second option may work for you. You can set the env var at any time
before you create a new SSLContext object.

Just to clarify: I am aware that for code we write/distribute, there are better ways (we tend to always use requests for http(s) handling). But as we are distributing python as a distribution, the goal is to make things work by default for 3rd party users, without compromising security, so 1. is not applicable. 2. is not a good solution in our opinion because it may cause trouble when people use programs linked against openssl through subprocess.

David

Christian

_______________________________________________
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig

blog: http://cournape.wordpress.com

code: https://github.com/cournape

twitter: @cournape