Paul Moore <p.f.mo...@gmail.com> added the comment:
OK, I don't really follow enough of the details here to comment properly. But clearly Steve and Eryk are not yet in agreement. My personal view is that this is something where we should be trying *very* hard to preserve backward compatibility. The proposal here is intended to solve the problem of making it easier for .pyd files to reliably load helper DLLs from shared locations. That's fine, and while it's an important use case (AIUI, it matters for a lot of the scientific stack) IMO it's *not* important enough to warrant breaking working scripts or embedding applications (particularly as this is a fairly obscure detail of how Windows works, so it's unlikely that people carefully follow "best practices" here). I'm very concerned that comments I've seen here, specifically >> 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. > > Only if they're loading them via PATH. If they're using full paths they'll be > fine, and if they're using system DLLs they'll be fine. In both cases, the > fix will work (better) with existing versions. > >> 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. > > That's true. "import" will always use the secure flags, and so if you were > relying on PATH to locate dependencies of the extension module (note that > extension modules themselves are loaded by full path, so it doesn't apply to > them), you need to stop doing that. imply that it's OK to break working code "because they are doing things wrongly". That's not how backward compatibility works - we should avoid breaking *any* working code, no matter how ill-advised it seems to be. If it's necessary to break code that (say) uses ctypes to load a DLL via PATH, or an embedding application that relies on getting DLLs using PATH, then we need to follow PEP 387 and go through a deprecation cycle for the existing behaviour. For the ctypes case I assume we can detect where we found the DLL being loaded, so warning that behaviour will change is certainly possible. For the embedding case, we could (for example) add an API Py_UseSecureSearchPath(bool) that embedders should call to opt into the new search semantics. With an explicit opt-in, we can then migrate that to be the default over time - have the Python API warn for a release if called without the opt-in, and then switch the default to be the secure search path, with applications that want to use the old search path being able to opt out using Py_UseSecureSearchPath(FALSE) for a release or two. That proposal is very much off the top of my head. But the point is that it's not impossible to make the transition follow the normal backward compatibility rules, and so we should do so. Of course, far simpler would be to choose a solution which *doesn't* break existing code :-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36085> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
