Network access during build for multiple recipes breaks build isolation

[pbeza]

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":

1. libnvidia-container: Also uses curl --insecure
2. dstack-guest: Go dependencies fetched during build
3. 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

1. Attacker compromises a dependency server or performs a MitM attack on the build network
2. During do_compile, the build fetches Go modules or other dependencies over the network
3. Fetched dependencies are not checksum-verified (unlike SRC_URI entries in do_fetch)
4. Malicious code is compiled into the resulting binaries
5. 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

1. Pre-fetch all Go dependencies during do_fetch with checksum verification:

SRC_URI += "file://vendor.tar.gz"
do_compile:prepend() {
    cp -r ${WORKDIR}/vendor ${S}/vendor
    export GOFLAGS="-mod=vendor"
}

2. Use Go module vendoring (go mod vendor) and include the vendor directory in the source
3. Remove do_compile[network] = "1" from all three recipes

---

Note: This issue was created automatically. The vulnerability report was generated by Claude and has not been verified by a human.

[kvinwang]

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.