-
Notifications
You must be signed in to change notification settings - Fork 3.3k
{Packaging} Bump PyWin32 to 305 #24982
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
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:
setuptoolsinjects_distutils_hack_distutils_hackcallssetuptoolssetuptoolscallspkg_resources([BUG] Importingsetuptoolsis slow and takes nearly half a second pypa/setuptools#3441)pkg_resourcesimportswin32com
Change
Bump PyWin32 (to >= 303) so that Azure CLI no longer loads
pywintypes310.dllorpythoncom310.dllfrom the current working directory (CWD), but always fromC:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\Lib\site-packages\pywin32_system32\.Context
LoadLibraryandLoadLibraryExWin32 APIAccording to https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications, even if
SafeDllSearchModeis enabled and it places the user's current directory later in the search order, the current directory is still searched byLoadLibraryandLoadLibraryEx.LoadLibraryExsupports additional flags such asLOAD_LIBRARY_SEARCH_DEFAULT_DIRSandLOAD_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:
LoadLibraryExWis called withLOAD_WITH_ALTERED_SEARCH_PATH.LoadLibraryExWis called withLOAD_LIBRARY_SEARCH_DEFAULT_DIRSandLOAD_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
_win32sysloaderswitched from callingLoadLibrarytoLoadLibraryExwith the sameLoadLibraryExflags 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: