libffi is doing releases again! We're a few versions behind, so should pull in the latest. https://github.com/libffi/libffi/

Adding RMs for opinions on backporting, and Ned in case this impacts the macOS build.

This first PR is just to avoid accidentally upgrading old builds. Otherwise, as soon as I push the new build into the cpython-bin-deps repository, it'll take precedence.

This one needs backporting into 3.10 and 3.9, but should be a no-op.

New changeset 969ae7f7356584e30667b4e490ffa2ffa1810429 by Steve Dower in branch 'main':
bpo-45022: Pin current libffi build to fixed version in preparation for upcoming update (GH-27982)
https://github.com/python/cpython/commit/969ae7f7356584e30667b4e490ffa2ffa1810429

New changeset 399cd466d0379d12e4af343a49ca7e8ec84997fa by Miss Islington (bot) in branch '3.9':
bpo-45022: Pin current libffi build to fixed version in preparation for upcoming update (GH-27982)
https://github.com/python/cpython/commit/399cd466d0379d12e4af343a49ca7e8ec84997fa

New changeset db36fdb1f42f490b7c2a3484a69aa1e6c72b6a4c by Miss Islington (bot) in branch '3.10':
bpo-45022: Pin current libffi build to fixed version in preparation for upcoming update (GH-27982)
https://github.com/python/cpython/commit/db36fdb1f42f490b7c2a3484a69aa1e6c72b6a4c

Realised that 3.8 needs the change to ensure it keeps using the same build of libffi. Obviously it won't be getting the new one (and since the new one is apparently a new API version, it may not even go into 3.10).

New changeset 8c3a10e58b12608c3759fee684e7aa399facae2a by Steve Dower in branch '3.8':
bpo-45022: Pin current libffi build to fixed version in preparation for upcoming update (GH-27982) (GH-28001)
https://github.com/python/cpython/commit/8c3a10e58b12608c3759fee684e7aa399facae2a

New changeset 6f8bc464e006f672d1aeafbfd7c774a40215dab2 by Steve Dower in branch 'main':
bpo-45022: Update libffi to 3.4.2 in Windows build (GH-28146)
https://github.com/python/cpython/commit/6f8bc464e006f672d1aeafbfd7c774a40215dab2

So on one hand, this change applies cleanly and it appears nothing needs to change to adopt the newer version.

On the other hand, because the libffi DLL has a different name, it changes the layout on disk. I know we don't do that (except in exceptional circumstances) after beta, but perhaps this one is safe enough? We certainly don't "support" directly accessing the libffi DLL, but it still could break users (if, for example, they load another native module that implicitly used the older libffi and would now fail to load when it's missing).

Any thoughts?

New changeset 4dc4300c686f543d504ab6fa9fe600eaf11bb695 by giovanniwijaya in branch 'main':
bpo-45022: Fix libffi DLL name in Windows installer sources (GH-28203)
https://github.com/python/cpython/commit/4dc4300c686f543d504ab6fa9fe600eaf11bb695

Going to just decide that we won't backport the update. If a big enough security issue is found we can consider it, but it would have to justify the potential-but-unlikely breaking change for users who are relying on the name of the DLL.

It seems this just broke our Windows build process of Python 3.8, since the cpython-bin-deps repository now contains only a libffi-8.lib while the the Python 3.8 branch still refers to libffi-7.lib in libffi.props: https://github.com/python/cpython/blob/5a42a49477cd601d67d81483f9589258dccb14b1/PCbuild/libffi.props#L13

The 3.8 branch has been updated to point to the `libffi-3.3.0` tag; you can either update to the latest revision of 3.8 or pull in just 8c3a10e58b12608c3759fee684e7aa399facae2a