[erikhortsch]

What changed

• The LiveKitWebRTC pin goes from 150.7871.03 to 150.7871.04 in all three places:
  • Package.swift (livekit/webrtc-xcframework, exact:)
  • Package@swift-6.2.swift (livekit/webrtc-xcframework, exact:)
  • LiveKitClient.podspec (LiveKitWebRTC pod dependency)
• Adds .changes/webrtc-drop-aaa-certificate-services-root (patch, fixed).

Why

On 2026-10-20 the keys of eight eMudhra intermediate CAs were disclosed as compromised. They are cross-signed by AAA Certificate Services.

libwebrtc checks TURN/TLS server certificates against its own compiled-in roots (rtc_base/ssl_roots.h), not the OS trust store. 150.7871.03 still includes AAA in that list, so it accepts a TURN/TLS server that presents a certificate from one of those intermediates.

All 7 AAA-cross-signed test chains from the disclosure pass openssl verify against the 150.7871.03 roots. None pass against the refreshed roots.

The fix is webrtc-sdk/webrtc fd5c784 ("Update ssl_roots.h (#317)"), a cherry-pick of upstream webrtc-review 510080, which is in 150.7871.04. 150.7871.04 is published as the livekit/webrtc-xcframework 150.7871.04 release, and the LiveKitWebRTC pod is in livekit/podspecs (#78).

Other notable changes in 150.7871.04 (webrtc-sdk/webrtc, vs .03)

• 67366b1 Put the privacy manifest in the framework's resources directory (macOS, Catalyst) (v1 Fix publish name #318)
• a545de4 feat(frame cryptor): add key_size to KeyProviderOptions (128 default, 256 opt-in) (fix: RemoteParticipants properties already empty when didDisconnect delegate invoked #302)
• 51c367e fix: Prevent raw_key/derived_key from leaking via LS_INFO (v1 fix Transport races #311)
• 67c4578 Verify server-injected frame payloads before skipping decryption (Simplify publish(data:options:) method #297)

Testing

CI passes against the published 150.7871.04.

The macOS Build & Test (macos-26, 26.6, macOS, true) job failed on two earlier attempts. Each failure was a different data-stream or data-track test, and that job is also red on main. Details are in the comments.

---

Generated by Claude Code

[erikhortsch]

lint (macos-15, 16.4) fails because pod lib lint can't resolve LiveKitWebRTC (= 150.7871.04). That pod hasn't been published yet. The SPM build jobs will fail the same way on webrtc-xcframework 150.7871.04. The PR's change is fine; it's waiting on the dependency.

The fix is the release itself. Once webrtc-sdk/webrtc-build#83 merges and 150.7871.04 is published to livekit/webrtc-xcframework and CocoaPods trunk, CI should pass without any change here. I'll re-run CI then. Until then this PR stays a draft.

---

Generated by Claude Code

[pblazej]

Thanks for looking into that, WebRTC build/publish is still in progress.

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[erikhortsch]

LiveKitWebRTC 150.7871.04 is now published (the tag on livekit/webrtc-xcframework exists), so the dependency blocker from my earlier comment is resolved. The other jobs are running against it now.

Lint is red because of the SwiftFormat Lint step (swiftformat --lint .), not this PR:

• It reports 113/476 files require formatting. The rules involved are sortImports (309 hits), nestedIf (64), repeatedGuard (27), extensionAttributes (22) and a few others, all in Swift sources this PR doesn't touch. This PR only changes the two Package*.swift version pins, the podspec and a .changes entry.
• main fails the same step: run 39948303434 on e4ec2e9 (Register the SDK's own transport with livekit-net #1106), job "Lint", step "SwiftFormat Lint". SwiftLint itself passes here with 0 violations.
• SwiftFormat isn't pinned in ci.yaml ("Comes pre-installed on macOS runners"), so a newer SwiftFormat on the runner image is the likely cause. This job ran on macos-26-arm64 image 20261021.0445.

I couldn't find an open fix. Two options for whoever owns CI: pin SwiftFormat to the last version that passed on main, or run swiftformat . once with the new version and commit the result in a separate PR. I'm not re-running, since main fails the same way every time.

---

Generated by Claude Code

[erikhortsch]

One test failed in Build & Test (macos-26, 26.6, macOS, true): -[ByteStreamReaderTests writeToFileRejectsSenderName(_:)]. Every other test in that job passed, including all 20 LiveKitObjCTests.

I don't think this PR causes it:

• The test exercises the data-stream writeToFile file-name check from Data streams v2 #1075. That's Swift-side path validation that doesn't go through WebRTC, and this PR only changes the LiveKitWebRTC version pin.
• After releasingManagerFailsOpenReader() the log stops for about 26 seconds, then a new "Selected tests" run starts. That looks like the test runner restarted mid-suite, not an assertion failure. I haven't confirmed this from the .xcresult.
• The same job is also red on main. Run 39948303434 on e4ec2e9 failed with other data-stream and signaling tests: IncomingStreamManagerTests.unhandledChunkedStreamIsReleased() and OfferWithJoinGateTests.staleSocketCallbacksAreIgnored(cancelled:).

I'll re-run the failed jobs once when this run finishes.

---

Generated by Claude Code

[erikhortsch]

Follow-up on the re-run (attempt 2, not started by me):

• Lint now passes, and so do all the other Build & Test jobs.
• One macOS Build & Test (macos-26, 26.6, macOS, true) job failed again, on a different test: -[DataTrackStressTests concurrentPush(_:)].
• It looks the same as attempt 1: the suite starts, the log goes quiet for about 29 seconds, then a new "Selected tests" run starts.

Each run fails a different data-stream or data-track test in this one job configuration. main (on LiveKitWebRTC 150.7871.03) fails the same job with other tests in the same area. So this looks like test-host instability in that job rather than something the version bump caused. I haven't checked the .xcresult crash logs to confirm. I'm not re-running again.

---

Generated by Claude Code