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

Comienza con el registro de publicación en numpy/numpy-release, revisión 72af5b09acd111d80b0e5bd9c1bcfcbec4b940b4, y luego rastrea los requisitos fijados de OpenBLAS y las recetas de Producer/Provider conservadas. Compara esos registros con los tres hashes de miembros del wheel indicados. Se considera terminado cuando se documenten los hashes de entrada exactos, las identidades de compilación de GCC/Conda, las referencias al código fuente y a los parches, y cualquier registro de reparación anterior/posterior que los vincule con el wheel de NumPy.

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:

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.