sdlc/ci: supply-chain & toolchain hardening; scheduled jco-browser and canary jobs #34

Activity

1. lann

   added

   enhancementNew feature or requestNew feature or request

   on Jul 26, 2026
2. lann commented on Jul 26, 2026

   

   lann

   on Jul 26, 2026

   CollaboratorAuthor

   More actions

   The jco-browser CI item is resolved by #39 — in a stronger form than asked: the target now gates in CI (the Actions runner ships Chrome ≥137, so JSPI needs no flags) rather than running as a scheduled non-gating job, with local runs opt-in via CONFORMANCE_BROWSER=1. Checkbox ticked.

   Still open here: supply-chain gating (cargo audit/deny, npm equivalent), npm ci in setup.sh, setup.sh version verification + pinned binstall bootstrap, SHA-pinned Actions, wasmtime CLI/crate lockstep, and the bleeding-edge canary job.
3. lann commented on Jul 28, 2026

   

   lann

   on Jul 28, 2026

   CollaboratorAuthor

   More actions

   Status note after #64, which touched this issue's territory without closing any of its boxes.

   Moved in this issue's direction:

   • Build provenance now has a precedent here. The toolchains release assets carry actions/attest-build-provenance attestations, because Publish the componentize-js toolchain; build the WPT runner every run #64 makes CI-built binaries part of the trust path (previously the published WPT components were built out-of-band and uploaded by hand, with no provenance at all). Whatever this issue settles on for release artifacts should extend that rather than invent a second scheme.
   • CI dropped contents: write. The publishing job lived in ci.yml; it is gone, and the workflow is contents: read throughout. Write permission is now confined to the toolchain workflow, which is the only thing that publishes.
   • One fewer floating input. scripts/wasm-tools.version was removed and the pin returned to a literal in setup.sh — relevant to the "setup.sh pins are aspirational" box, which still stands: every install remains guarded by have <tool>, so whatever is on PATH still wins.

   Added surface for the SHA-pinning box:

   • .github/workflows/componentize-js-toolchain.yml uses actions/checkout@v5 and actions/attest-build-provenance@v2, both tag-pinned like the rest. It also git clones and builds a third-party repository at a pinned SHA, then publishes the result as a release asset — worth an explicit line in whatever policy this issue lands on, since it is the one place the repository produces a binary from source it does not control.
4. lann commented on Jul 28, 2026

   

   lann

   on Jul 28, 2026

   CollaboratorAuthor

   More actions

   #90 added the first new runtime dependency this repository has taken since these boxes were filed, which makes it the first test of the gating they ask for — and it went in without any of it.

   wasmtime-impl now depends on mea = \"0.6\" (its only dependency, slab, was already in the tree via wasmtime), replacing a hand-written admission queue with mea::semaphore::Semaphore. The evaluation was done by hand: 1.76M downloads in 90 days, 32 dependants including OpenDAL and foyer, one maintainer, pre-1.0 so minor bumps may churn the API. That is a reasonable basis for a decision and no basis at all for a policy — nothing in CI would have objected, and nothing will notice if a future version of it, or of anything below it, acquires an advisory.

   Concretely, against the boxes here:

   • Supply-chain gating — a cargo audit/cargo deny job would now have something to say about a 0.x dependency on the crypto host's critical path, and there is still no dependabot to tell us when it moves.
   • SHA-pinned Actions / verified setup.sh pins — unaffected, still open.

   Also worth recording next to the npm ci box: mea is pre-1.0, so "0.6" permits 0.6.x but not 0.7. Cargo.lock pins the exact version, and CI builds from the lockfile, so the floating range is bounded in practice — the gap is that nothing reviews the movement, not that the range is loose.
5. lann commented on Aug 6, 2026

   

   lann

   on Aug 6, 2026

   CollaboratorAuthor

   More actions

   #342 pinned the cargo-binstall bootstrap by version and digest (the curl | bash half of the third checklist item). The other half — verifying installed versions against the pins when have <tool> short-circuits — remains, as does the header-doc omission of WAC_VERSION/WASMTIME_VERSION.
6. lann

   added a commit that references this issue on Aug 6, 2026

   ci: install just in the webkit jobs via the pinned binstall bootstrap

   ...

   98fe893
7. lannbot commented on Aug 12, 2026

   

   lannbot

   on Aug 12, 2026

   Contributor

   More actions

   Movement on the SHA-pinning box's parenthetical: cdca413 pinned node-version: 24.19.0 across the workflows (forced by the Node 24.19 Ed25519 admission shift that reddened wpt-parity on every branch — #376), so the 'node-version: 24 floats across 24.x' clause is resolved. The rest of the box stands: checkout@v5, setup-node@v4, rust-cache@v2, cache@v4 etc. are still tag-pinned (the polymorph-test setup action is the one SHA-pinned uses:). Also re-verified today: setup.sh still runs npm install (not ci) at five sites, still verifies nothing when have <tool> short-circuits, and the wasmtime CLI/crate lockstep gap persists (CLI pin 47.0.1, Cargo.lock resolves 47.0.2). No cargo audit/deny or dependabot yet.
8. lannbot commented on Aug 17, 2026

   

   lannbot

   on Aug 17, 2026

   Contributor

   More actions

   Supply-chain surface update from the JSR consumption migration (#385): the JS runner core now arrives from npm.jsr.io via per-tree .npmrc scope routing (@jsr/polymorph__test, exact-pinned, lock integrity), replacing the npm-git pin. Two facts for this ledger:

   • The deltic driver's deno.json exempts jsr:@deltic/* and jsr:@polymorph/* from Deno's 24-hour minimumDependencyAge quarantine — deliberate (same-day family releases must resolve), and low-risk while every family dep is exact-pinned with a frozen lock, but it is a standing carve-out this issue's future dependabot/audit items should know about.
   • npm.jsr.io joins registry.npmjs.org and jsr.io as a registry the builds trust.