[Leechael]

The gateway, KMS and verifier runtime images pinned ca-certificates=20230311+deb12u1 from the 20260317T000000Z Debian snapshot. That trust store still contains emSign ECC Root CA - G3 and Comodo AAA Services root, so any client in those images that reads the system store (curl, and the Rust services through rustls-platform-verifier until they get rustls-webpki 0.103.16) accepts a certificate issued by one of the compromised eMudhra/emSign intermediate CAs.

Changes

• dstack/build/shared/pin-packages.sh: default SNAPSHOT_DATE 20260317T000000Z -> 20261021T000000Z.
  • snapshot.debian.org first lists ca-certificates 20250419~deb12u2 (bookworm) in debian-security at 20261020T213255Z, and 20250419+deb13u1 (trixie) at 20261020T205625Z. 20261021T000000Z is the first midnight timestamp after both.
  • I fetched debian-security/20261021T000000Z/dists/{bookworm,trixie}-security/main/binary-amd64/Packages.xz and checked that they list 20250419~deb12u2 and 20250419+deb13u1.
• ca-certificates:

list	before	after
gateway pinned-packages.txt	20230311+deb12u1	20250419~deb12u2
kms pinned-packages.txt	20230311+deb12u1	20250419~deb12u2
verifier pinned-packages.txt	20230311+deb12u1	20250419~deb12u2
verifier builder-pinned-packages.txt	20230311+deb12u1	20250419~deb12u2
gateway / kms builder-pinned-packages.txt	20250419	20250419 (unchanged, see below)

• The other pins moved only where the old pinned version no longer exists in the new snapshot. All of them are Debian security updates:
  • runtime (bookworm): openssl/libssl3 3.0.18-1deb12u2 -> 3.0.22-1deb12u1 (all three); curl/libcurl 7.88.1-10+deb12u14 -> deb12u15, krb5 1.20.1-2+deb12u4 -> deb12u5, libnghttp2 1.52.0-1+deb12u2 -> deb12u3 (gateway, verifier); jq/libjq 1.6-2.1+deb12u1 -> deb12u3, libcap2 1:2.66-4+deb12u2+b2 -> deb12u3+b1 (gateway).
  • builders: openssl/libssl 3.5.5-1deb13u1 -> 3.5.7-1deb13u3, protobuf 3.21.12-11 -> 3.21.12-11+deb13u1, musl 1.2.5-3 -> 1.2.5-3.1~deb13u1 (gateway, kms); openssl/libssl 3.0.18 -> 3.0.22, protobuf 3.21.12-3 -> 3.21.12-3+deb12u1 (verifier).

The gateway and KMS builder stages keep ca-certificates=20250419. Their apt step does not install ca-certificates, so the pin cannot move the copy that ships in the rust:1.92.0 base image. That trust store is only used at build time (git clone, crate download; crates are checked against the Cargo.lock checksums). Listed under remaining work.

How the lists were generated

No build-image.sh run on this box: it clones the pushed revision and does the full release build. Instead, for each of the six stages I ran the same base image (same digest) with the new pin-packages.sh and the edited list, ran the stage's exact apt-get install line, and wrote dpkg -l the way extract_packages does. A second pass that used the regenerated lists as input gave byte-identical lists for all six stages. That is the same check verify-pinned-packages.sh does in CI.

Plain http to snapshot.debian.org is blocked from this box, so for these generation runs only I rewrote the sources to https inside the throwaway containers. apt still checked the InRelease signatures. The committed pin-packages.sh is unchanged apart from the date.

Self-test against the emSign test site

A container from the pinned debian:bookworm base, with the verifier runtime list and apt-get install ca-certificates curl:

== next (20260317T000000Z, ca-certificates 20230311+deb12u1)
/etc/ssl/certs has emSign_ECC_Root_CA_-_G3.pem and Comodo_AAA_Services_root.pem
curl https://dv-g3b-emudhra.we-have-a-problem.com/ -> HTTP 200
== this branch (20261021T000000Z, ca-certificates 20250419~deb12u2)
emSign_ECC_Root_CA_-_G3.pem and Comodo_AAA_Services_root.pem gone (emSign Root CA - C1, G1 and ECC C3 remain)
curl: (60) SSL certificate problem: unable to get local issuer certificate
control: https://www.google.com/ -> HTTP 200

Tests run

• The two-pass list regeneration above (all six lists idempotent).
• python3 -m unittest test_build_lib in dstack/build/shared/tests: 6 tests pass.

Not run here

• The full build-image.sh builds and the Docker Build Check workflow. Its verify-pinned-packages.sh steps on this PR are the authoritative check.
• No reproducibility comparison against a published image.

Rollout impact

Every rebuilt image (gateway, KMS, verifier) has a new digest, so the compose hash of each CVM that runs it changes. Register the new compose hashes in the on-chain allowlists and auth configs before rolling out. Anything that pins the verifier image by digest has to move to the new image as well.

Remaining

• The gateway/KMS builder trust store (ca-certificates 20250419 from the rust base image). Fixing it means adding ca-certificates to the builder apt-get install line or moving to a newer rust base image. It only affects the build stage, so I left it out of this PR.
• This PR does not change the binaries. The Rust fix is on branch security/emsign-rust-workspace.