Trusts the libffi library inside of nixpkgs on Apple devices.
When Apple's fork of libffi is not detected, cffi assumes that libffi
uses a strategy for creating closures (i.e. callbacks) that is in
certain cases susceptible to a security exploit.
Based on some analysis I did:
https://groups.google.com/g/python-cffi/c/xU0Usa8dvhk
I believe that libffi already contains the code from Apple's fork that
is deemed safe to trust in cffi.
It uses a more sophisticated strategy for creating trampolines to
support closures that works on Apple Silicon, while the simple approach
that cffi falls back on does not, so this patch enables code that uses
closures on M1 Macs again.
Notably, pyOpenSSL is impacted and will be fixed by this, reported in
https://github.com/pyca/pyopenssl/issues/873
Note that libffi closures still will not work on signed apps without the
com.apple.security.cs.allow-unsigned-executable-memory entitlement while
https://github.com/libffi/libffi/pull/621
is still open (which I haven't tested but is my best guess from reading).
I am hopeful that all of these changes will be upstreamed back into cffi
and libffi, and that this comment provides enough breadcrumbs for future
maintainers to track and clean this up.
This adds a test to ensure no new uses of `buildPythonApplication` can
be added to `python-packages.nix`.
Python packages can be grouped into two groups: 1) applications and 2)
packages providing importable modules. In `python-packages.nix` we only
want to have 2). 1) should be in the top-level package set.
To achieve this, all setup hooks need to be marked as being a setup hook.
For the setup hooks in the Python packages set this is done by creating
a new builder, `makePythonHook`.
Because there were issues with splicing, the file importing all the hooks
is converted to an extension. All non-packages were moved out of `python-packages.nix`
into `python-packages-base.nix`. The `keep` argument to `makeScopeWithSplicing
was cleaned up as well; there is no need to keep this one manually in sync
reducing the risk of breaking cross-compilation.
