Python 3.13.16 macOS framework seal verification after installation #159629

Summary

After installation of the official python-3.13.16-macos11.pkg, strict signature verification of the installed framework reported a sealed-resource error and added pip/documentation files. The separate interpreter launcher passed verification. I am seeking clarification of the expected installed-framework behavior and a supported way to establish its integrity and signing identity.

This is one observed installation, not a confirmed CPython defect or evidence of tampering.

Environment and package

• Platform: macOS. The exact OS version/build was not recorded in the retained diagnostic capture.
• Package: python-3.13.16-macos11.pkg from python.org.
• Package SHA-256: 30666509020b4da0dd8bc2e773255f34d76b7bb80b66960a928d5f6daa0192d7.
• Installed patchlevel.h declares 3.13.16; Python was not manually launched to obtain a runtime version.
• Launcher signing metadata reports a universal x86_64/arm64 executable.
• In the owner's Terminal context, pkgutil --check-signature returned 0 and reported the Python Software Foundation Developer ID Installer chain to Apple Root CA and trusted Apple notarization. This installer result does not establish the installed framework's integrity.

Observed checks

These commands were run once by the owner; this report summarizes retained output, not a new reproduction:

/usr/bin/codesign --verify --strict --verbose=2 /Library/Frameworks/Python.framework/Versions/3.13/bin/python3.13

Returned 0: valid on disk and satisfies its Designated Requirement. A separate signing-information display returned 0 and identified Python Software Foundation, Team ID BMM5U3QVKW.

/usr/bin/codesign --verify --strict --verbose=2 /Library/Frameworks/Python.framework/Versions/3.13/Python

Emitted this diagnostic:

/Library/Frameworks/Python.framework/Versions/3.13/Python: a sealed resource is missing or invalid

Its output also listed added pip3, pip3.13, and many documentation HTML files.

Important limitation: a wrapper imposed a 65,536-byte per-output-file limit. The framework check reached that limit and was terminated with SIGXFSZ; the wrapper recorded exit status 153. This is not codesign's normal final exit status. The added-file enumeration is incomplete. The negative diagnostic was emitted before termination, and the subsequent framework signing-information display was not reached.

A separate read-only review of the saved outputs confirmed these observations and limitations; it did not reproduce the check or establish the cause.

Related report and question

I found the December 28, 2020 contributor comment in #86234 describing framework verification failure after pip adds files. That issue concerns Tcl/Tk packaging and does not establish the cause or a verification procedure for this installation.

Is the observed added pip/documentation behavior expected from this installer? What supported procedure should establish the installed framework's integrity and signing identity while accounting for the seal diagnostic? I am not seeking to suppress verification failures or remove/re-sign resources without understanding them.

A related inquiry was sent to pythonmac-sig; no response is included in the evidence used for this report. No raw logs are attached. No signature retry, repair, or security-setting change has been performed as part of preparing this report. Normal installer-script behavior was not separately traced.