fix(security): verify the iOS xcframeworks, and verify on every run rather than only a cold download - #2349
Merged
Merged
Conversation
…ather than only a cold download Claude-Session: https://claude.ai/code/session_013MEaba8K1HQcyDNeq5wEFk
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
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
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.
The iOS xcframeworks were downloaded, extracted and linked with no integrity check of any kind, in CI included. 299 MB across 424 files, straight into a shipped app.
Two holes, not one
The iOS archive had no baseline at all.
download-libs.shverified the macOS.afiles againstLibs/checksums.sha256committed in git, and did nothing whatsoever forLibs/ios.The macOS check almost never ran either. The script opened with two
exit 0short-circuits: one on the.downloadedmarker, one on finding any.apresent.actions/cacherestoresLibsincluding the marker, so on a cache hit, which is what CI takes on nearly every run, the script returned before reaching the checksum step. The verification existed and was skipped.What this does
Libs/ios/checksums.sha256is now committed, covering all 424 regular files rather than just the library slices. TheInfo.plistinside an.xcframeworkis what selects which slice gets linked, so leaving it unhashed would leave a live tampering surface.Libs/ios/is gitignored, and git cannot re-include a file whose parent directory is excluded, so the pattern becomesLibs/ios/*plus a negation. Verified that onlychecksums.sha256becomes trackable andgit add Libs/ios/still stages nothing else.download-libs.shis restructured so verification runs at the end, always, for both archives, whether or not anything was downloaded. The baselines are still read fromHEADbefore any extraction, for the reason the old comment already gave: each archive bundles its own checksums file, so verifying against the extracted copy is self-referential.publish-ios-libs.shis new, because a baseline nothing regenerates is a baseline that breaks everyone on the next rebuild. CLAUDE.md documented publishing as a baretar czf … && gh release upload, which bypasses all of this; it now points at the script. The script reports what moved before publishing, refuses a publish where nothing changed, archives an allowlist rather than-C Libs/ios ., and tells you to commit the refreshed baseline.Verified by exercising every path
exit 0Info.plistbyte changedERROR: Libs/ios does not match,exit 1exit 1The baseline was also checked for stability: generating it twice produces identical bytes, and
shasum -cverifies all 424 files against the tree.One bug found by running it rather than reading it: the two baselines use different path conventions.
Libs/checksums.sha256holdsLibs/…paths and must be checked from the repo root, while the iOS one holds./…paths and must be checked from insideLibs/ios. The first versioncd'd for both and failed every macOS library with "FAILED open or read".A behaviour change worth calling out
Verification now runs against whatever is on disk, so rebuilding a library locally and then running anything that calls
download-libs.shfails rather than passing silently. That is the point, and the error names the two publish scripts. The alternative is what exists today: CI force-loading unverified static libraries into a signed, notarized binary because a cache hit skipped the check.https://claude.ai/code/session_013MEaba8K1HQcyDNeq5wEFk