python: use PyConfig_InitIsolatedConfig to initialize the embedded Python#5515
python: use PyConfig_InitIsolatedConfig to initialize the embedded Python#5515philiptaron wants to merge 1 commit intofontforge:masterfrom
Conversation
…thon From the [docs](https://docs.python.org/3/c-api/init_config.html#init-isolated-conf): > `PyConfig_InitIsolatedConfig()` creates a configuration to isolate Python > from the system. This is ideal to embed Python into an application. > > This configuration ignores global configuration variables, environment > variables, command line arguments (`PyConfig.argv` is not parsed) and > user site directory. The C standard streams (ex: stdout) and the > `LC_CTYPE` locale are left unchanged. Signal handlers are not installed. > > Configuration files are still used with this configuration to determine > paths that are unspecified. Ensure `PyConfig.home` is specified to avoid > computing the default path configuration. This will change the default behavior of Python in FontForge from loading whatever is in the current working directory to loading what's installed as part of the system Python or the venv Python, which ever gets loaded as the shared library.
|
Some of the tests failed with Python module errors: 👀 |
|
It seems like this raises a lot of potential issues and would require some communication at a minimum. The main benefit would be a slightly decreased attack surface but FontForge is already incredibly insecure. Our guideline about untrusted input isn't directly related but I'm tempted to refer to it anyway: https://github.com/fontforge/fontforge/wiki/Community-guidelines#D1 |
Actually, that was an incredibly helpful reference. Plus the set of failing tests, it made me realize the impact here for making this the default is... not worth the squeeze. For nixpkgs's packaging of FontForge, I might pursue this approach, since it makes much more sense in that context. In NixOS/nixpkgs, there is an assumption about hermeticity that's not present in the broader Python ecosystem. There are also simple ways of constructing a Python "system" environment with a crafted set of packages just for FontForge. None of those hold true in the general case. Given all that, I'm closing this PR. Thank you for your time and attention. |
Motivation for change
Reduce surprising and security-sensitive loading of Python modules based on the current working directory where the
fontforgeprogram is run. After this change, the Python scripts which are explicitly loaded based onfontforge's command line flags, plus hard-coded ones likepkg_resources, are the only ones used.This is a breaking change!
From the docs:
This will change the default behavior of Python in FontForge from loading whatever is in the current working directory to loading what's installed as part of the system Python or the venv Python, which ever gets loaded as the shared library.
Breaking changes
safe_path). The files processed byLoadFilesInPythonInitDirwill still be loaded.