-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
{Packaging} Bump PyWin32 to 305 #24982
Conversation
Bump PyWin32 to fix vulnerability issue |
Why/How
|
setuptools==52.0.0 |
which doesn't injects _distutils_hack
. But the Windows MSI bundles latest setuptools
65.6.3 and results in the following call chain:
setuptools
injects_distutils_hack
_distutils_hack
callssetuptools
setuptools
callspkg_resources
([BUG] Importingsetuptools
is slow and takes nearly half a second pypa/setuptools#3441)pkg_resources
importswin32com
Change
Bump PyWin32 (to >= 303) so that Azure CLI no longer loads
pywintypes310.dll
orpythoncom310.dll
from the current working directory (CWD), but always fromC:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\Lib\site-packages\pywin32_system32\
.Context
LoadLibrary
andLoadLibraryEx
Win32 APIAccording to https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications, even if
SafeDllSearchMode
is enabled and it places the user's current directory later in the search order, the current directory is still searched byLoadLibrary
andLoadLibraryEx
.LoadLibraryEx
supports additional flags such asLOAD_LIBRARY_SEARCH_DEFAULT_DIRS
andLOAD_LIBRARY_SEARCH_DLL_LOAD_DIR
. When these flags are specified, directories in the standard search path are not searched, so the current directory is no longer searched.Python 3.8's DLL loading mechanism change
https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-python-api
bpo-36085 is migrated to python/cpython#80266.
In summary, when loading DLLs:
LoadLibraryExW
is called withLOAD_WITH_ALTERED_SEARCH_PATH
.LoadLibraryExW
is called withLOAD_LIBRARY_SEARCH_DEFAULT_DIRS
andLOAD_LIBRARY_SEARCH_DLL_LOAD_DIR
, more securely (bpo-36085: Enable better DLL resolution on Windows python/cpython#12302)PyWin32's DLL loading mechanism change
Since version 303, PyWin32's
_win32sysloader
switched from callingLoadLibrary
toLoadLibraryEx
with the sameLoadLibraryEx
flags as Python itself mhammond/pywin32#1794.Therefore, PyWin32's change causes the current directory no longer to be searched, but its change log doesn't mention this:
https://github.com/mhammond/pywin32/blob/d73b0200eba81fa551b90d15cf5da097f4197f8f/CHANGES.txt#L92-L93
Testing guide
The test can be done with system Python, without Azure CLI's embedded Python.
With PyWin32 302, DLL can be loaded from the current directory:
With PyWin32 305, DLL cannot be loaded from the current directory and results in an
ImportError
: