core: Find Python-bundled libcrypto on Windows#319
Open
djdarcy wants to merge 1 commit into
Open
Conversation
On Python 3.8+ Windows, ctypes.util.find_library() can't see Python's
own DLLs/ dir because it's no longer on the DLL search path. Fall back
to scanning sys.{base_,}prefix/DLLs for libcrypto-*.dll before
LoadLibrary(None) raises TypeError.
Layered on top of petertodd#306, which only works on systems that already have
libcrypto.dll in system32 from another package.
Closes petertodd#316.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hey @petertodd! On Python 3.8+ Windows,
ctypes.util.find_library()can't see Python's ownDLLs/directory because it's no longer on the default DLL search path. So even though Python shipslibcrypto-3.dllin<sys.base_prefix>/DLLs/, every candidate in the existing chain ('ssl.35','ssl','libeay32','libcrypto'from #306) returns None, and_ssl = ctypes.cdll.LoadLibrary(None)raisesTypeError: argument of type 'NoneType' is not iterableon import.This set of changes adds a 4th fallback, as
_find_bundled_libcrypto(), that checkssys.base_prefix/DLLs/andsys.prefix/DLLs/directly for anylibcrypto-*.dllfile. On a fresh Python 3.10+/3.11+/3.12+ Windows install where the bundled OpenSSL is the only one available, import should now work without requiring users to install OpenSSL system-wide.FWIW: the BN_* / EC_* functions this module actually calls live in libcrypto, not libssl. On Linux/macOS libssl typically re-exports libcrypto symbols so loading libssl works; on Windows they are in separate DLLs, hence preferring
libcrypto-*.dll.No behavior change on Linux/macOS --
_find_bundled_libcrypto()returns None early whensys.platform != 'win32'.Relates to #318, which takes a different approach (raises
EnvironmentErrorwhen nothing is found). The two PRs should be complementary: this fix tries to actually find OpenSSL, and #318'sEnvironmentErrorwould be the right thing if even this fallback finds nothing. Happy to defer or combine in any order you prefer.Closes #316.
Ran a basic test on Python 3.12 + Win11 with
bitcoin/tests/test_key.pypassing (1/1).