Skip to content

[Backport release-22.11] python310Packages.cffi: patch closures to work on M1 machines#203450

Merged
vcunat merged 1 commit intostaging-next-22.11from
backport-187636-to-release-22.11
Dec 19, 2022
Merged

[Backport release-22.11] python310Packages.cffi: patch closures to work on M1 machines#203450
vcunat merged 1 commit intostaging-next-22.11from
backport-187636-to-release-22.11

Conversation

@github-actions
Copy link
Contributor

Bot-based backport to release-22.11, triggered by a label in #187636.

  • Before merging, ensure that this backport complies with the Criteria for Backporting.
    • Even as a non-commiter, if you find that it does not comply, leave a comment.

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

  pyca/pyopenssl#873

Note that libffi closures still will not work on signed apps without the
com.apple.security.cs.allow-unsigned-executable-memory entitlement while

  libffi/libffi#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.

(cherry picked from commit 4fc97dc)
@ofborg ofborg bot requested review from LnL7 and domenkozar November 28, 2022 13:36
@ofborg ofborg bot added 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 5001+ This PR causes many rebuilds on Darwin and must target the staging branches. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches. labels Nov 28, 2022
@vcunat vcunat changed the base branch from release-22.11 to staging-next-22.11 December 19, 2022 10:41
@github-actions github-actions bot added the 6.topic: python Python is a high-level, general-purpose programming language. label Dec 19, 2022
@vcunat vcunat merged commit f47c2f4 into staging-next-22.11 Dec 19, 2022
@vcunat vcunat deleted the backport-187636-to-release-22.11 branch December 19, 2022 10:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

6.topic: python Python is a high-level, general-purpose programming language. 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 5001+ This PR causes many rebuilds on Darwin and must target the staging branches. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants