Repository navigation
Python 3.13.16 macOS framework seal verification after installation #159629
Description
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.pkgfrom python.org. - Package SHA-256:
30666509020b4da0dd8bc2e773255f34d76b7bb80b66960a928d5f6daa0192d7. - Installed
patchlevel.hdeclares 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-signaturereturned 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.
Activity
picnixz commentedon Oct 17, 2026
cc @python/macos-team
ned-deily commentedon Oct 19, 2026
Thanks for the report. It does point out that there are some problems with attempting to use
codesignto verify the Pythons installed by the python.org macOS installers. One root of the problems is that the file and directory layout of a macOSPython.frameworkwas established years before Apple tightened security requirements for flat package (.pkg) installations, first with code signing and then with notarization. The second root problem is that some of the package installer settings and options cause files to be installed within the codesigned framework bundle, either during installation or afterwards, thus invalidating its seal.Specific problem areas include: installation of the optional documentation within the signed framework; the creation of
.pycbytecode files for the standard library.pyfiles during post-installation; and the location of thesite-packagesdirectory, the default installation location for third-party modules and packages including pip, within the signed framework. Because most of these locations have been in use for many years, existing packages and tools may be depending on these locations so we need to be careful about making changes to them. We will need to come up with a plan for this.But, to address the higher-level question here, which I believe is essentially "How do I verify the integrity of a python.org macOS Python installation?", the best approach today is to follow the steps outlined in the How to verify your downloaded files are genuine section of the
Download Pythonpage including using Sigstore to verify the downloaded installer package and to check the Apple notarization status of the.pkgfile (for example,pkgutil --check-signature python-3.15.0-macos11.pkg).