Publish provenance attestations and reproducible build metadata for FFI/WebRTC release assets

[ibragimmiftah-ops]

Context

We are evaluating the Linux x86_64 native chain consumed by livekit Python 1.1.13. PyPI provenance successfully binds the wheel to livekit/python-sdks commit 2a38ec0cedb42514270349c3aebdca66171c5cf4 and workflow run 28442189540, attempt 10. The wheel contains the expected FFI binary, but the downloaded FFI and WebRTC release assets do not appear to have their own public artifact attestations or a complete reproducible-build manifest.

This is a supply-chain/compliance request, not a vulnerability report.

Exact Artifacts Reviewed

• Python wheel: livekit-1.1.13-py3-none-manylinux_2_28_x86_64.whl, SHA-256 f4e83f0e272f4b2e9cc39dbefd7bb23b75bd8c105478d867c2869254ca4e149a.
• FFI release: livekit-ffi/v0.12.68, source commit dad794d414fda9e8c1de83af1c0f190506a15f8f.
• FFI archive ffi-linux-x86_64.zip SHA-256: 9e8818b1af2a57f5f587fb4996d5d55557dea2e332fc18c184a8840ed0515bf1.
• Linux FFI binary liblivekit_ffi.so SHA-256: c3c3b6dae263b78ae74cf5d7d58b9a67b8ed51d4c3a01c487e044d516eb7297a.
• WebRTC release: webrtc-51ef663, release commit 71e3a03e53205b65c6ca04f21339a58fc1a40eae.
• WebRTC archive webrtc-linux-x64-release.zip SHA-256: dce9d9414cd8e2cc9a471c054481851b257ad2a879112ce5be56369b4fefdaed.
• Candidate m144_release branch tip observed during evaluation: aaeeee8077eb0a4cad1c9494e9c6433c751ef663; this is not proven to be the revision used for the release.

Evidence Gaps

The current public build/source chain does not appear to provide all of the following:

1. Artifact attestations for the FFI and WebRTC release archives.
2. A digest check when the FFI build downloads the WebRTC archive.
3. An immutable WebRTC commit in .gclient rather than the moving m144_release branch.
4. The exact bootstrap depot_tools revision used by the release build. build_linux.sh clones current HEAD, although the candidate WebRTC DEPS graph separately pins 8efa575d754b8703d99b0f827528e45aeaa167aa.
5. Evidence that the checked-in Cargo.lock was enforced during release builds, for example with cargo build --locked and, where feasible, --frozen.
6. For Linux x86_64, the exact GitHub runner image identity and digest of sameli/manylinux_2_28_x86_64_cuda_12.3; the workflow currently uses ubuntu-latest and a tag-only container reference.
7. A release-bound manifest proving the exact WebRTC checkout and native materials used, including FFmpeg. The candidate branch graph points to FFmpeg 583a135878d38065ef1e3d08cd80b7fbe76e0a7b, but is not bound to the published release asset.
8. Release-bound corresponding-source and relinking materials, or another mechanism relied upon for LGPL compliance, sufficient to relink the FFmpeg-containing static native chain. The existing custom-build path and partial build files do not establish exact relinking of the published binary.

Request

Would the project be able to publish, for future FFI/WebRTC releases:

• GitHub artifact attestations or equivalent SLSA provenance for each FFI/WebRTC native release asset, at least for Linux x86_64;
• SHA-256 checksums consumed and verified by downstream build workflows;
• source commit, workflow run/attempt, runner image, container digest and toolchain versions;
• the complete resolved WebRTC checkout/material manifest;
• locked/frozen Cargo build evidence; and
• release-bound corresponding-source/relink materials, or the alternative mechanism relied upon for LGPL compliance, for statically bundled LGPL components?

If equivalent evidence already exists, links to it would be very helpful. We are also happy to split this into smaller actionable issues if preferred.

Thank you.