Steve Dower <steve.do...@python.org> added the comment:

> use AddDllDirectory, (which is as accessable as os.environ['PATH'] but is not 
> considered a security risk so far)

The parenthical is incorrect. The user-specified DLL search directory is 
separate from PATH, and both appear in the default DLL search order when 
resolving relative paths. In more secure configurations, PATH is not used for 
DLL resolution.

> but this requires using SetDefaultDllDirectories which breaks other things

Specifically, it breaks any extension relying on the implicit default search 
order by enabling one of the more secure configurations.

> put any dlls required for the c-extension pyd in the same directory which 
> means scipy and numpy will be using duplicate and potentially different 
> OpenBLAS dlls, and whoever imports first wins

Doesn't scipy import numpy? Which means numpy wins every time. Or 
alternatively, put "-numpy" in the name of numpy's one and "-scipy" in the name 
of scipy's one, and you can have both.

> load all the required dlls via LoadLibrary, meaning NumPy will have to export 
> a windows-only API to SciPy so the latter can know where the DLL is.

Perhaps that API could be exported via normal module import as is currently is? 
That way scipy can just "import numpy" to locate numpy?

Alternatively, if you do indeed need to have shared state with scipy, then you 
should come up with an API that they can depend on. This is how shared state 
normally works.

> Is there a PEP that describes the overall design of windows directory layout 
> or a design guide for package authors with best practices for additional dll 
> dependencies?

No, but there is a doc page that deserves an update: 
https://docs.python.org/3/extending/windows.html

If we make a dramatic change to CPython here, then there may be a PEP, but it 
should still defer to the documentation as that is what gets updated over time.

Currently, the best info comes from 
https://docs.microsoft.com/windows/desktop/Dlls/dynamic-link-library-search-order
 and awareness that only the LOAD_WITH_ALTERED_SEARCH_PATH flag is used when 
loading extension modules (see 
https://github.com/python/cpython/blob/master/Python/dynload_win.c#L221)


Since I just saw the confirmation at 
https://docs.microsoft.com/en-us/windows/desktop/Dlls/dynamic-link-library-search-order#search-order-using-load_library_search-flags,
 I don't think we can safely change the LoadLibraryEx option in CPython until 
we drop support for Windows 7 completely, as the update containing the new 
flags may not be installed. If/when we do that, it will break any extension 
relying on unsafe DLL search semantics (that is, anything appearing in the 
earlier section but not in this section).

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35688>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to