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

numpy/numpy-release の公開レコード、リビジョン 72af5b09acd111d80b0e5bd9c1bcfcbec4b940b4 から始め、固定された OpenBLAS 要件と保持されている Producer/Provider レシピを追跡してください。これらのレコードを、一覧にある 3 つの wheel-member ハッシュと比較してください。正確な入力ハッシュ、GCC/Conda のビルド ID、ソースおよびパッチの参照、ならびにそれらを NumPy wheel に結び付ける修復前後の記録があれば、完了です。

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.