Use OpenSSL's official privacy manifest for _ssl/_hashlib - #35
Merged
Conversation
The manifest bundled into _ssl.framework and _hashlib.framework was a stub: NSPrivacyAccessedAPITypes was an empty array, and it carried an NSPrivacyUsesNonStandardAPIs key that isn't part of Apple's schema. Both frameworks statically link OpenSSL, so the manifest should be the one OpenSSL publishes for its Apple builds — it declares the file-timestamp API access (NSPrivacyAccessedAPICategoryFileTimestamp, reason C617.1) that the library actually performs. Now byte-identical to openssl/openssl:os-dep/Apple/PrivacyInfo.xcprivacy. Context: flet-dev/flet#6724 reports ITMS-91065 ("Missing signature") for both frameworks on a first App Store submission. This does not obviously explain that rejection — Apple emitted no ITMS-91061, so it found the manifest — but an incomplete manifest for a binary Apple has fingerprinted as OpenSSL is a real defect worth eliminating before we test further.
FeodorFitsner
added a commit
to flet-dev/serious-python
that referenced
this pull request
Jul 26, 2026
Re-pins the bundled python-build snapshot to 20260726, which replaces the stub PrivacyInfo.xcprivacy bundled into _ssl.framework and _hashlib.framework with the manifest OpenSSL publishes for its Apple builds (flet-dev/python-build#35). No versions moved: Python 3.12.13 / 3.13.14 / 3.14.6, Pyodide, and dart_bridge 1.6.1 are all unchanged from 20260725. This is a correctness fix, not a fix for the ITMS-91065 rejection in flet-dev/flet#6724 — see the serious_python_darwin 4.4.1 entry for what was ruled out and what remains open.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
darwin/PrivacyInfo.xcprivacy— the manifest copied into_ssl.frameworkand_hashlib.framework— was a stub:NSPrivacyAccessedAPITypeswas an empty<array/>NSPrivacyUsesNonStandardAPIs, which is not a key in Apple's schemaBoth frameworks statically link OpenSSL (
stringson the shipped_sslbinary reportsOpenSSL 3.5.7), so the right manifest is the one OpenSSL publishes for its Apple builds. This file is now byte-identical toopenssl/openssl:os-dep/Apple/PrivacyInfo.xcprivacy, which declares the file-timestamp API access the library actually performs (NSPrivacyAccessedAPICategoryFileTimestamp, reasonC617.1).plutil -lintclean.Why now
flet-dev/flet#6724 — a first App Store submission rejected with ITMS-91065: Missing signature for both
Frameworks/_ssl.framework/_sslandFrameworks/_hashlib.framework/_hashlib, citing BoringSSL / openssl_grpc.This change is not expected to fix that, and shouldn't be presented as the fix. Apple emitted no ITMS-91061 alongside it, so it did find the manifest. Inspecting a real Flet IPA ruled out every signature-side explanation:
TeamIdentifier--forcere-signs on embed; Google's own signature onFlutter.frameworkis overwritten with the app team's in the same IPAplutilcleanfilesandfiles2of_CodeSignature/CodeResourcesSo the framework reaches Apple signed, with a sealed privacy manifest, and is still reported as unsigned. Root cause is still open; a DTS incident is the next step if a first-party submission reproduces it.
What this PR does is remove the one concrete defect that was verifiable, so it isn't a confound in that test.
Follow-up
Needs a python-build release, then a snapshot re-pin in
flet-dev/serious-python, before it reaches an app build.