chore: bump CodeScanner and Lottie, pin all SPM dependencies to exact versions

[dependabot]

Description

Opened by Dependabot as a 3-dependency group bump. swift-secp256k1 was dropped from it (see below), so the net change is two version bumps plus a change to how all SPM dependencies are constrained.

Dependency versions

Dependency	Change
CodeScanner	2.5.1 → 2.5.2
lottie-ios	4.5.2 → 4.6.1
swift-secp256k1	unchanged at 0.17.0 — bump reverted in 50f8825

swift-secp256k1 removed from the bump. 0.23.2 renames the secp256k1 product to P256K and moves the raw C API into a separate libsecp256k1 product, so every target failed to load with Missing package product 'secp256k1'. Migrating needs project and source changes across Crypto.swift, WatchOnlyAccountService.swift and all scripted xcodebuild invocations, which touches push-notification payload decryption and watch-only key parsing. That is split into #659, with a working patch attached there.

All dependency requirements pinned to exactVersion (94e9728). Following @pwltr's review comment: CodeScanner, lottie-ios and swift-secp256k1 were the only three references still using upToNextMajorVersion, and Dependabot had tightened CodeScanner's floor while leaving Lottie's untouched. They now match the four Synonym/pubky packages, so all 7 references are exact pins.

The practical effect is review visibility. Under a floating range a version change can land with the project file untouched, visible only in the generated Package.resolved; under exact pins every bump is an explicit edit to project.pbxproj and shows up in the diff. This is also what let secp256k1 jump 0.17.0 → 0.23.2 across a breaking rename in the first place. There is no downside here specifically: Bitkit is a leaf app with no transitive dependencies (7 references, 7 resolved entries), so exact pins cannot cause the diamond conflicts that make them a bad idea in libraries.

Change-set review. Both upstream diffs were reviewed with a reachability check against our call sites — summary in this comment. No new capabilities, no new runtime dependencies, no privacy-manifest or entitlement changes, and no change to how scanned payment data is handled. Notably, Lottie vendors ZipFoundation 0.9.16 → 0.9.20, which carries an upstream zip-slip path-escape fix — unreachable for us, since we only load bundled JSON animations, never dotLottie.

Net diff: project.pbxproj (6 lines) and Package.resolved (4 lines).

Automated Checks

Build succeeds and the unit-test suite passes locally with these versions (756 tests, 0 failures), on the same simulator and skip-list CI uses.

No changelog fragment: chore, no user-facing change.

Linked Issues/Tasks

• Migrate swift-secp256k1 to the P256K module (0.17.0 → 0.23.x) #659 — Migrate swift-secp256k1 to the P256K module (follow-up, carries the reverted bump)

Screenshot / Video

N/A

[greptile-apps]

PR author is in the excluded authors list.

[jvsena42]

@dependabot rebase

[dependabot]

Looks like this PR has been edited by someone other than Dependabot. That means Dependabot can't rebase it - sorry!

If you're happy for Dependabot to recreate it from scratch, overwriting any edits, you can request @dependabot recreate.

[jvsena42]

@dependabot recreate

[pwltr]

Why did it tighten minimumVersion here but not for Lottie? We only have 3 external dependencies, so I think we can afford to be strict on their versions - In light of recent security concerns - and get into the habit of reading their change sets.

[jvsena42]

Why did it tighten minimumVersion here but not for Lottie?

Probably there was not a clear pattern for the bot follow, since this is the first PR. I'll move the dependency declaration kinds to exactVersion for safety and consistency

[jvsena42]

done in 94e9728

[jvsena42]

Dependency change-set review

Per @pwltr's point about reading change sets: below is a review of the actual upstream diffs, not the release notes, with a reachability check against Bitkit's call sites. swift-secp256k1 was reverted in 50f8825, so only two dependencies are bumping here.

Bottom line: no new capabilities, no new runtime dependencies, no privacy-manifest or entitlement changes, and nothing that alters how scanned payment data is handled. Both bumps are safe to land.

---

CodeScanner 2.5.1 → 2.5.2 (compare)

Three files, one of them source: ScannerViewController.swift, +20/-15. That is the entire shipped change.

Change	Reachable from Bitkit?
didFail(reason:) now dispatches the completion to the main queue	Yes — fixes a potential crash when a camera/permission failure fires off the main thread into our SwiftUI completion handler
Photo-library import path hardened: drops features as! [CIQRCodeFeature] and feature.messageString!, adds an empty-features guard	No — Bitkit/Components/Scanner.swift:12 is our only CodeScannerView call site and it never enables the gallery picker, so this path is dead code for us

The important part for a wallet: the scanned string passthrough is unchanged. No modification to how a QR payload is read or delivered, so nothing here touches BIP-21 / invoice / LNURL parsing. The diff is purely crash-hardening — replacing force-unwraps with guards.

Lottie 4.5.2 → 4.6.1 (compare)

300 files across 26 commits, which looks alarming until you split it. The overwhelming majority is mechanical reformatting (closing-paren and trailing-comma style) from the airbnb/swift style package moving 1.0.x → 1.2.0. The substantive changes:

Vendored libraries refreshed

• ZipFoundation 0.9.16 → 0.9.20 — this is the bulk of the real churn. It carries genuine security fixes from upstream: 0.9.18 fixed a path-escape (zip-slip) vulnerability and added enforceable symlink containment; 0.9.20 fixed a resource leak, a memory leak in Data.readChunk, and a memory-alignment crash.

• EpoxyCore 0.10.0 → 0.11.0

  ZipFoundation only backs dotLottie (.lottie) files, which are ZIP archives. Bitkit never loads one — our only two Lottie call sites (SendSuccess.swift:42, ReceivedTx.swift:38) use LottieAnimation.filepath() on plain JSON resolved via Bundle.main.url(forResource:withExtension:). So the ZIP parser is compiled into the binary but not reachable from any Bitkit code path, and no untrusted input reaches it. We inherit the hardening for free.

loadedFrom(url:) refactor — the signature moves from session: URLSession = .shared to session: LottieURLSession = LottieConfiguration.defaultURLSession, and gains proper task cancellation. Worth being explicit since it shows up in a capability scan as new URLSession code: this is not a new network capability. Remote animation loading already existed in 4.5.2 with the same default; this is an injectability/cancellation refactor. Bitkit calls neither overload — we load only from the bundle.

Package manifest — swift-tools-version 5.9 → 6.0 with swiftLanguageMode(.v5) (so no Swift 6 language-mode migration is forced on us), and .custom("visionOS") replaced by the first-class .visionOS platform. The airbnb/swift dependency bump is lint/format tooling and does not reach consumers: our Package.resolved still contains exactly 7 packages and gained nothing.

No changes to PrivacyInfo.xcprivacy, Info.plist, or entitlements in either dependency.

---

Scope of this review

I read the CodeScanner source diff in full, and for Lottie I scanned all ~13k changed source lines for capability changes — networking, filesystem writes, dynamic loading, process spawning, credential/storage access — then read the security-relevant hunks and both vendored libraries' upstream release notes. I did not audit all 300 Lottie files line by line; the reformatting churn was not individually reviewed.

Verified locally with the versions in this PR: build succeeds and the unit-test suite passes (756 tests, 0 failures).