Context
We are evaluating the Linux x86_64 native chain in livekit Python 1.1.13. PyPI provenance successfully binds the wheel to livekit/python-sdks commit 2a38ec0cedb42514270349c3aebdca66171c5cf4 and workflow run 28442189540, attempt 10. However, the workflow downloads the FFI release archive by tag without verifying an expected digest before packaging its native library into the wheel.
This is a supply-chain hardening 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 asset
ffi-linux-x86_64.zip SHA-256: 9e8818b1af2a57f5f587fb4996d5d55557dea2e332fc18c184a8840ed0515bf1.
- Packaged binary
livekit/rtc/resources/liblivekit_ffi.so SHA-256: c3c3b6dae263b78ae74cf5d7d58b9a67b8ed51d4c3a01c487e044d516eb7297a.
Request
Would the project be able to bind each supported-platform FFI asset to an expected SHA-256 digest and verify it immediately after download in the Python release workflow?
Publishing GitHub artifact attestations or equivalent SLSA provenance for the upstream FFI assets, then recording and verifying that provenance in the Python wheel build, would additionally make the native source-to-wheel chain independently verifiable.
If equivalent integrity verification already exists outside the reviewed workflow, a link would be very helpful. Thank you.
Context
We are evaluating the Linux x86_64 native chain in
livekitPython1.1.13. PyPI provenance successfully binds the wheel tolivekit/python-sdkscommit2a38ec0cedb42514270349c3aebdca66171c5cf4and workflow run28442189540, attempt 10. However, the workflow downloads the FFI release archive by tag without verifying an expected digest before packaging its native library into the wheel.This is a supply-chain hardening request, not a vulnerability report.
Exact Artifacts Reviewed
livekit-1.1.13-py3-none-manylinux_2_28_x86_64.whl, SHA-256f4e83f0e272f4b2e9cc39dbefd7bb23b75bd8c105478d867c2869254ca4e149a.livekit-ffi/v0.12.68, source commitdad794d414fda9e8c1de83af1c0f190506a15f8f.ffi-linux-x86_64.zipSHA-256:9e8818b1af2a57f5f587fb4996d5d55557dea2e332fc18c184a8840ed0515bf1.livekit/rtc/resources/liblivekit_ffi.soSHA-256:c3c3b6dae263b78ae74cf5d7d58b9a67b8ed51d4c3a01c487e044d516eb7297a.Request
Would the project be able to bind each supported-platform FFI asset to an expected SHA-256 digest and verify it immediately after download in the Python release workflow?
Publishing GitHub artifact attestations or equivalent SLSA provenance for the upstream FFI assets, then recording and verifying that provenance in the Python wheel build, would additionally make the native source-to-wheel chain independently verifiable.
If equivalent integrity verification already exists outside the reviewed workflow, a link would be very helpful. Thank you.