Windows: conda-standalone may fail with no OPENSSL_Applink with official Python installed

[marcoesters]

Checklist

• I added a descriptive title
• I searched open reports and couldn't find a duplicate

What happened?

Some users report failures with Miniconda 24.5.0, which uses conda-standalone 24.5.0 as the bootstrapper. One example can be found here: ContinuumIO/anaconda-issues#13408

Further debugging showed that the release binaries for conda-standalone 24.5.0 produce the same error:

OPENSSL_Uplink(00007FFB01AE2FE8,08): no OPENSSL_Applink

There appears to be a correlation with users having an official Python installed. I cannot reproduce the problem though.

Miniconda 24.4.0, which uses conda-standalone 24.3.0, works fine though.

Conda Info

N/A

Conda Config

N/A

Conda list

N/A

Additional Context

A lot of things have changed between conda-standalone 24.3.0 and 24.5.0, most notably the Python and pyinstaller versions got updated.

However, the packages on defaults were both built with pyinstaller 5.13.2.

[jaimergp]

Thanks to @guitarpicker, we learnt that this problem occurs when the SSLKEYLOGFILE environment variable is set. This is used to dump debugging information from SSL transactions to the chosen file.

After some debugging @marcoesters and I got to the conclusion that this is indirectly caused by a change introduced in requests 2.32 (note this is going to be reverted, though).

That PR calls this function on import:

from urllib3.util.ssl_ import create_urllib3_context

create_urllib3_context()

And that causes the reported crash. We are only observing this in the latest 24.5.0 build because of the requests update. But if we run the above code in any other conda-standalone version, it crashes in the same way:

> conda-standalone-24.4.0-Windows-x86_64.exe python -c "from urllib3.util.ssl_ import create_urllib3_context as c; c()"
OPENSSL_Uplink(00007FFCF30D0FE8,08): no OPENSSL_Applink

> conda-standalone-24.3.0-Windows-x86_64.exe python -c "from urllib3.util.ssl_ import create_urllib3_context as c; c()"
OPENSSL_Uplink(00007FFCF3240FE8,08): no OPENSSL_Applink

> conda-standalone-24.1.2-Windows-x86_64.exe python -c "from urllib3.util.ssl_ import create_urllib3_context as c; c()"
OPENSSL_Uplink(00007FFCF323AFE8,08): no OPENSSL_Applink

The root cause is not well understood (possibly in this CPython C code block, plus some interaction with PyInstaller?), but we can workaround the issue by unsetting the SSLKEYLOGFILE before it reaches the requests import. This is what we are doing in #89.

[guitarpicker]

The root cause is not well understood (possibly in this CPython C code block, p

I'm out of my lane and don't feel confident about posting in the upstream repo, but after taking a cursory looking at that block, I notice it's using BIO_new_fp(fp, BIO_CLOSE | BIO_FP_TEXT); and there's this note in the man page that:

When wrapping stdout, stdin or stderr the underlying stream should not normally be closed so the BIO_NOCLOSE flag should be set."

I'm not sure if this is the same thing, but from my recent experience I can tell you that the SSLKEYLOGFILE target file is usually being referenced by some process or another where I can't do any sort of deletion or modification. Mine is still locked by MS Edge (and probably Chrome and potentially any other log aware program as well) since I haven't gotten around to restarting my user session since reporting my findings. Perhaps BIO_CLOSE allows some file operations to be attempted that will fail where perhaps BIO_NOCLOSE would succeed.

[marcoesters]

I currently think it's much more likely that it is due to how conda-standalone is built. You can convince yourself by running the following:

conda-standalone-24.5.0-Windows-x86_64.exe python -c "from urllib3.util.ssl_ import create_urllib3_context; c
reate_urllib3_context()"

And do the same thing with vanilla python or even a conda-installed python. Only conda-standalone will fail. We even tried packaging that command into a pyinstaller-created binary to see if it's a pyinstaller bug and it still succeeds. So, if the code itself was problematic, I would expect it to fail consistently.

I would also expect a different error message if it was some kind of access violation.