fix(ios): record cocoapods 1.17.0 podspec checksums in Podfile.lock

[ethicnology]

The "Upload App Store Connect" workflow fails at pod install --deployment with lockfile checksum changes for the 5 CocoaPods plugins (flutter_secure_storage_legacy, rust_lib_bull_sdk, tor, universal_ble, webview_cookie_manager).

Root cause

fba70b0 hand-edited the COCOAPODS: line in ios/Podfile.lock from 1.16.2 to 1.17.0 without regenerating the lockfile. The workflow pins CocoaPods to the version recorded in the lockfile, so CI now runs 1.17.0 — whose podspec JSON serialization differs from 1.16.2 (the exact behaviour the pin was added for in 84e478f). The committed SPEC CHECKSUMS were still the 1.16.2 values, so --deployment correctly rejected them.

The plugin sources themselves are unchanged: all five are pinned by ref/version in pubspec.lock and their podspec files are identical; only the checksum serialization changed.

Fix

Record the checksums CocoaPods 1.17.0 actually computes, as reported by the failed run (run #4, "New Lockfile" values). No other lockfile drift was reported (Flutter pod, PODFILE CHECKSUM, and the dependency graph all matched).

[claude]

Claude finished @ethicnology's task in 2m 19s —— View job

---

Review: PR #2672 — record CocoaPods 1.17.0 podspec checksums

Verdict: LGTM. No correctness bugs, security issues, or regressions found. (Note: I can't post formal inline review comments — findings with file/line references are included here instead.)

Todos

• Gather context: inspect the Podfile.lock change and related workflow/pins
• Verify the claims (checksums-only change, CocoaPods version pin, plugin sources unchanged)
• Check CI results
• Post review summary

What I verified

The fix matches the pinning mechanism it serves. .github/workflows/upload-app-store-connect.yml:189-195 reads the COCOAPODS: line from ios/Podfile.lock and installs exactly that gem version before running pod install --deployment. With the lockfile declaring 1.17.0 (ios/Podfile.lock:47) but the committed SPEC CHECKSUMS still being 1.16.2 serializations, --deployment correctly failed. Updating the five checksums (ios/Podfile.lock:39-43) is the right resolution given the intent of the earlier version bump; reverting the COCOAPODS: line to 1.16.2 would also have worked but would walk back that bump.

Security: no supply-chain weakening. SPEC CHECKSUMS are SHA-1s of the podspec JSON serialization, not a content-integrity control for the pod sources. The actual sources of all five affected plugins are pinned independently in pubspec.lock, which is unchanged:

• flutter_secure_storage_legacy — git resolved-ref: 01ed2ee0… (pubspec.lock:798)
• rust_lib_bull_sdk — git resolved-ref: 62977e2f… (pubspec.lock:1710)
• tor — git resolved-ref: b92e2bc5… (pubspec.lock:2045)
• universal_ble — pub.dev sha256: 8325ca9f…, v1.2.0 (pubspec.lock:2069)
• webview_cookie_manager — git resolved-ref: e0395449… (pubspec.lock:2270)

So accepting the checksums reported by the failed CI run doesn't let modified code in — a wrong checksum would only re-fail --deployment, and pod content is anchored by the pubspec.lock pins. The fix is self-verifying: the next workflow run's pod install --deployment re-validates these exact values against what CocoaPods 1.17.0 computes.

Consistency of the diff. The change is exactly +5/−5 in ios/Podfile.lock, touching only the five plugin checksum lines. The Flutter pod checksum (line 38), PODFILE CHECKSUM (line 45), and the PODS/DEPENDENCIES/EXTERNAL SOURCES sections are untouched, matching the PR's claim that only serialization of the plugin podspecs changed. The cocoapods-* cache key (upload-app-store-connect.yml:121) hashes the lockfile, so the downloads cache rotates cleanly — no stale-cache risk.

Limitations

I couldn't independently recompute the SHA-1 values (that requires CocoaPods 1.17.0's podspec JSON serialization on a macOS runner with the plugin podspecs resolved), and the shallow checkout prevented inspecting the referenced historical commits (fba70b006, 84e478f73). Neither affects the conclusion: an incorrect checksum fails closed in CI rather than producing a bad build.

---