Open layday opened 4 years ago
There is a default search path for x509 certificates compiled into the OpenSSL/LibreSSL that is bundled with the Python distribution that PyOxidizer is using. This default search path likely only works on Debian[-derived] distributions. We'll need to teach the PyOxidizer runtime to locate and use the host machine's default x509 certificate store. We already do this for the terminfo database (https://github.com/indygreg/PyOxidizer/blob/24ac847868c22ae7a8517e3fd77dddd7d5c1c7b7/pyembed/src/interpreter.rs#L214). We'll likely employ a similar trick for x509 certificates.
Trying to build a package using pyoxidizer for the first time, and ran smack into this issue. While I can hardcode the Fedora paths, the package also needs to support Windows. Without pyoxidizer, this seems to work fine for all platforms:
context = ssl.create_default_context(ssl.Purpose.SERVER_AUTH)
(I assume this is more relevant to
python-build-standalone
but I'm reporting it here since I've experienced it with PyOxidizer.)Using the low-level SSL and socket APIs, attempting to make an SSL connection on a fresh install of Fedora 32 fails with:
After some modest digging, I discovered that the CA paths differ between the Fedora-vendored Python and PyOx's own Python. This is the return value of
__import__('ssl').get_default_verify_paths()
with Fedora's Python:And this is PyOxidizer:
When creating a new SSL context, the SSL module calls
set_default_verify_paths
with the output ofget_default_verify_paths
. The PyOxopenssl_cafile
,/etc/ssl/cert.pem
, does not exist, whatever that might be indicative of;/etc/ssl/certs
is a symlink to/etc/pki/tls/certs
. You can repro this by bundling:In effect this means that you cannot make any HTTPS requests at all on Fedora out of the box using PyOx.