Build provenance of GCC runtime libraries in NumPy 2.5.2 macOS arm64 wheel

[dario7s]

We are checking the corresponding source and build provenance of compiler runtime libraries in the NumPy2.5.2 CPython3.13 macOS arm64 wheel. We have retained these public evidence joins:

• NumPy wheel SHA256:52c808f96484f5571a5cc863775ce50247c17dfb3b0361f8ed6b4b0456f80080.
• The publication record points to numpy/numpy-release revision72af5b09acd111d80b0e5bd9c1bcfcbec4b940b4. Its OpenBLAS requirements pin scipy-openblas32/64==0.3.34.0.0, consistent with the wheel's reported OpenBLAS version.
• The retained OpenBLAS producer recipe selects the gcc-11.3.0-2 arm64-native provider package. That provider recipe selects versioned Conda components and removes conda-meta; the public records we found do not identify the exact underlying package builds and patches.

The three final wheel members are:

Member	SHA256
numpy/.dylibs/libgfortran.5.dylib	728b8a719b0b015422632c74de2913ed14d82b319bc3a0643830bd506492662e
numpy/.dylibs/libgcc_s.1.1.dylib	baee2e6118dd54c0852f881d718516d70884de84bfaa085de5d8d8f90baa3b06
numpy/.dylibs/libquadmath.0.dylib	1b341ae276c4adcb30c070b774ec6e68e819c883e897f0de8941d553f7989a0d

Could you provide the exact producer wheel/input hashes, GCC/Conda package build identities and corresponding source/patch references for these three libraries, ideally with the build or repair record that ties them to this NumPy wheel? Loader-path repair or signing can change final bytes, so an explicit before/after record would also help.

We are not reporting an exploit or evidence of tampering. The question is limited to exact source and packaging provenance. We do not need credentials, private user data or access to your infrastructure.

[mattip]

Who is "we"? Your user is less than 1 month old, and has no further information about yourself. In an open source community like NumPy, we like to know who we are talking to.

But giving you the benefit of the doubt, here is a trail. This may not be the exact version you are looking for but the trail has been the same for a few years now.

These three shared objects are repackaged from the scipy-openblas package by delocate. That package's latest build delocate log shows they come from /opt/gfortran/gfortran-darwin-arm64-native, which in turn comes from https://github.com/isuruf/gcc/releases/download/gcc-11.3.0-2/gfortran-darwin-arm64-native.tar.gz. Going back one step, isuruf/gcc builds gcc from forked sources of gcc.