Summary
master CI is broken. The build-and-test job fails at the Build module step (nix build -L) on both ubuntu-latest and macos-latest. It is not a code regression — re-running master's own last-green commit (9b22b52, originally green 2026-05-26) now fails reproducibly.
Symptom
The Nix build fails fetching a handful of Rust crates from crates.io:
trying https://crates.io/api/v1/crates/alloy-rlp/0.3.13/download
curl: (22) SSL certificate ... unable to get local issuer certificate (20)
curl: (22) The requested URL returned error: 403
error: cannot download crate-alloy-rlp-0.3.13.tar.gz from any mirror
Only 4 crates fail (all RLN/zerokit deps pulled in via the logos-chat rust bundle):
alloy-rlp, ark-bn254, ark-circom, ark-crypto-primitives.
Failing runs (all PRs against master, plus master re-run):
- master re-run of
9b22b52: run 26462630550 → failure
experiment/try-remove-deferred-emit: run 26589693972 → failure
expand_e2e_coverage: runs 26575763494, 26478213518, 26463159157 → failure
Root cause
crates.io now enforces its data-access policy by User-Agent. The /api/v1/crates/{name}/{version}/download endpoint returns 403 for a bare curl/* UA:
$ curl -s https://crates.io/api/v1/crates/serde/1.0.0/download
{"errors":[{"detail":"We are unable to process your request at this time. This usually means that you are in violation of our API data access policy ... "}]}
$ curl -A "cargo 1.93.0" -o /dev/null -w "%{http_code}" https://crates.io/api/v1/crates/serde/1.0.0/download
302 # works with a cargo UA
Nixpkgs' importCargoLock (used by buildRustPackage { cargoLock.lockFile = ...; } in logos-chat/nix/rust_bundle.nix and nix/libchat.nix) fetches each crate tarball via fetchurl from exactly that endpoint, with a curl/* UA → 403.
Why only 4 crates / why now: most crate tarballs are served from the logos-co Cachix cache, so they never re-fetch. These 4 are a cache miss (verified: their FOD narinfo returns 404 from logos-co.cachix.org), so they fall back to crates.io and fail. Master was green on 2026-05-26 off a warm cache / before crates.io began enforcing this.
The pinned nixpkgs (e9f00bd893…) hardcodes:
"https://github.com/rust-lang/crates.io-index" = "https://crates.io/api/v1/crates";
nixpkgs fixed this in commit f830e6112b4d (2026-05-27) — "rustPlatform.importCargoLock: download crates from static.crates.io" — switching to:
"https://github.com/rust-lang/crates.io-index" = "https://static.crates.io/crates";
static.crates.io serves the same path format and is not UA-gated (verified 200).
Fix options
- Durable (recommended): in
logos-messaging/logos-chat, bump the nixpkgs input used by the rust bundle to a rev that includes nixpkgs f830e6112b4d (2026-05-27) or later, so importCargoLock fetches from static.crates.io. Then bump the logos-chat input rev in this repo's flake.nix / flake.lock. (Same cargoLock change applies to nix/libchat.nix.)
- Immediate unblock (no code change): re-warm the
logos-co Cachix cache with the 4 missing crate FODs (e.g. build with a nixpkgs that uses static.crates.io and cachix push). Restores the green state without touching the pins.
Notes
- Also surfaced (non-blocking):
actions/checkout@v4 and cachix/cachix-action@v15 run on the soon-deprecated Node.js 20.
Summary
masterCI is broken. Thebuild-and-testjob fails at the Build module step (nix build -L) on bothubuntu-latestandmacos-latest. It is not a code regression — re-running master's own last-green commit (9b22b52, originally green 2026-05-26) now fails reproducibly.Symptom
The Nix build fails fetching a handful of Rust crates from crates.io:
Only 4 crates fail (all RLN/zerokit deps pulled in via the
logos-chatrust bundle):alloy-rlp,ark-bn254,ark-circom,ark-crypto-primitives.Failing runs (all PRs against master, plus master re-run):
9b22b52: run26462630550→ failureexperiment/try-remove-deferred-emit: run26589693972→ failureexpand_e2e_coverage: runs26575763494,26478213518,26463159157→ failureRoot cause
crates.io now enforces its data-access policy by User-Agent. The
/api/v1/crates/{name}/{version}/downloadendpoint returns 403 for a barecurl/*UA:Nixpkgs'
importCargoLock(used bybuildRustPackage { cargoLock.lockFile = ...; }inlogos-chat/nix/rust_bundle.nixandnix/libchat.nix) fetches each crate tarball viafetchurlfrom exactly that endpoint, with acurl/*UA → 403.Why only 4 crates / why now: most crate tarballs are served from the
logos-coCachix cache, so they never re-fetch. These 4 are a cache miss (verified: their FOD narinfo returns 404 fromlogos-co.cachix.org), so they fall back to crates.io and fail. Master was green on 2026-05-26 off a warm cache / before crates.io began enforcing this.The pinned nixpkgs (
e9f00bd893…) hardcodes:nixpkgs fixed this in commit
f830e6112b4d(2026-05-27) — "rustPlatform.importCargoLock: download crates from static.crates.io" — switching to:static.crates.ioserves the same path format and is not UA-gated (verified 200).Fix options
logos-messaging/logos-chat, bump the nixpkgs input used by the rust bundle to a rev that includes nixpkgsf830e6112b4d(2026-05-27) or later, soimportCargoLockfetches fromstatic.crates.io. Then bump thelogos-chatinput rev in this repo'sflake.nix/flake.lock. (SamecargoLockchange applies tonix/libchat.nix.)logos-coCachix cache with the 4 missing crate FODs (e.g. build with a nixpkgs that uses static.crates.io andcachix push). Restores the green state without touching the pins.Notes
actions/checkout@v4andcachix/cachix-action@v15run on the soon-deprecated Node.js 20.