You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Network access during build for multiple recipes breaks build isolation #46
Several recipes in meta-dstack/ fetch source tarballs over the network during the Yocto build using SRC_URI with HTTP(S) URLs, making the build non-reproducible and vulnerable to supply-chain attacks if the upstream source is compromised.
Root Cause
Three build recipes enable network access during compilation via do_compile[network] = "1":
libnvidia-container: Also uses curl --insecure
dstack-guest: Go dependencies fetched during build
dstack-sysbox: Go dependencies fetched during build
Yocto's default build isolation disables network access during do_compile to ensure reproducibility and supply-chain integrity. When do_compile[network] = "1" is set, dependencies are fetched at build time without the checksum verification that SRC_URI provides in do_fetch.
Attack Path
Attacker compromises a dependency server or performs a MitM attack on the build network
During do_compile, the build fetches Go modules or other dependencies over the network
Fetched dependencies are not checksum-verified (unlike SRC_URI entries in do_fetch)
Malicious code is compiled into the resulting binaries
Affected binaries are included in the dstack guest image
Impact
Supply-chain integrity gap. Dependencies fetched during compilation bypass Yocto's integrity verification. A compromised upstream server or network attacker can inject malicious code into three components: NVIDIA container runtime, dstack guest agent, and sysbox container runtime.
Suggested Fix
Pre-fetch all Go dependencies during do_fetch with checksum verification:
Thanks for the report. We looked into this and here's where things stand:
The core issue is valid — do_compile[network] = "1" bypasses BitBake's do_fetch checksum verification. However, the practical risk is low because both Cargo (Cargo.lock) and Go (go.sum) perform their own cryptographic hash verification of dependencies at download time.
Why we can't fully vendor into the repo:
dstack-guest (Rust/Cargo):cargo vendor produces a ~1.2 GB directory with 40k files. Committing this to the repo is not feasible.
dstack-sysbox (Go): The dependencies live across 3 separate upstream repos (nestybox), each needing its own vendor directory. Maintenance overhead is high.
The fully correct fix would be hosting vendor tarballs as SRC_URI resources with checksums, but the added release process complexity doesn't justify the marginal security gain given that the package managers already verify hashes.
What we did fix:
libnvidia-container: Already ships a vendor directory in the source tree. Now builds fully offline using GOFLAGS=-mod=vendor, and do_compile[network] has been removed.
We consider the current state acceptable for the other two recipes.
Activity
kvinwang commentedon Mar 18, 2026
Thanks for the report. We looked into this and here's where things stand:
The core issue is valid —
do_compile[network] = "1"bypasses BitBake'sdo_fetchchecksum verification. However, the practical risk is low because both Cargo (Cargo.lock) and Go (go.sum) perform their own cryptographic hash verification of dependencies at download time.Why we can't fully vendor into the repo:
cargo vendorproduces a ~1.2 GB directory with 40k files. Committing this to the repo is not feasible.The fully correct fix would be hosting vendor tarballs as
SRC_URIresources with checksums, but the added release process complexity doesn't justify the marginal security gain given that the package managers already verify hashes.What we did fix:
libnvidia-container: Already ships a vendor directory in the source tree. Now builds fully offline usingGOFLAGS=-mod=vendor, anddo_compile[network]has been removed.We consider the current state acceptable for the other two recipes.
fix: build libnvidia-container without network access