This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients brett.cannon, eric.snow, eryksun, jkloth, lukasz.langa, mattip, ncoghlan, paul.moore, steve.dower, tim.golden, zach.ware
Date 2019-03-12.05:48:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1552369683.59.0.87199200227.issue36085@roundup.psfhosted.org>
In-reply-to
Content
> call SetDefaultDllDirectories() in Py_Main (i.e. not when embedded) 
> to ensure secure search paths are always used

That will require rewriting many scripts and packages that use ctypes or cffi to load DLLs. It would also break DLLs that internally rely on modifying PATH for a delayed load, though I hope that's uncommon. I think it's easier for everyone else if we implement this just for extension-module loading with the LoadLibraryExW flags. 

Also, if I'm understanding your intention, loading an extension may fail when Python is embedded if the process is using the legacy DLL search path. So, like with ctypes, we'll be forcing embedding applications to update how they load DLLs in order to comply with us, else they'll have to accept that some packages won't work without the SetDefaultDllDirectories call.

> ensure LoadLibrary when used in ctypes or importing will use the 
> correct flags

ctypes calls LoadLibraryW, which uses the default that's set by SetDefaultDllDirectories, if that's what we eventually decide is the best course of action.

If we decide to not call SetDefaultDllDirectories, then we should provide a way for ctypes packages to update to using the secure search path instead of relying on the legacy search path. We could rewrite the ctypes LoadLibrary wrapper to call LoadLibraryExW instead of LoadLibraryW and support the flags in the CDLL `mode` parameter, which is currently unused in Windows.

> add sys._adddlldirectory() and sys._removedlldirectory() as CPython-
> specific functions for extending the search path (for use by packages 
> currently modifying PATH at runtime)

I'd prefer some way for scripts and packages to configure their shared-library search paths as static data. The implementation would be kept private in the interpreter. 

I know there's debate about removing ".pth" files. But maybe we could  implement something similar for the DLL search path with package and script ".pthext" files. These would contain a list of directories (relative to the script or package) that extend the shared-library search path.

> add check for KB2533623 to the installer and block if it is not
> present

Also, at runtime we can raise a SystemError if AddDllDirectory isn't found via GetProcAddress. This supports portable Python installations.
History
Date User Action Args
2019-03-12 05:48:03eryksunsetrecipients: + eryksun, brett.cannon, paul.moore, ncoghlan, tim.golden, jkloth, lukasz.langa, eric.snow, zach.ware, mattip, steve.dower
2019-03-12 05:48:03eryksunsetmessageid: <1552369683.59.0.87199200227.issue36085@roundup.psfhosted.org>
2019-03-12 05:48:03eryksunlinkissue36085 messages
2019-03-12 05:48:03eryksuncreate