build(deps): exclude fastq@1.20.2 from the npm trust policy, reviewed

[wenzowski]

Closing: superseded on main while this was in flight. CLOUD-1136 was fixed by another session, and that fix is strictly better than this one.

origin/main at ec2c9c15 already carries fastq@1.20.2 in trust_policy_excludes, and its comment covers everything this PR's did plus three things it did not:

• the npm signing key is identical across the two publishes (SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U), which is a stronger identity check than the maintainer-name comparison here;
• a release-age cooldown was evaluated and ruled out with reasons — mise's npm backend exposes seven tool options and none is a quarantine, aube_args only applies under a different package manager, and MISE_MINIMUM_RELEASE_AGE governs tool selection rather than transitive npm resolution;
• bumping renovate to 44.50.3 was tried and reverted, with the finding recorded: it fails on the identical fastq@1.20.2 anyway (fastq arrives transitively under a caret range, so no top-level pin decides it) and it breaks renovate-config-validator, because renovate 44 reads RENOVATE_CONFIG as inline JSON5 while this repo's task uses that name for a path seam.

The two reviews agree independently on the finding that matters — same gitHead, matching the real v1.20.2 tag, a manual publish by the sole maintainer outside the OIDC workflow, benign. That agreement is worth something, but it does not justify a second commit touching the same six lines.

The evidence gathered here is on CLOUD-1136 as a comment and stays useful there: the tarball-versus-tag diff -r (no differing file), the absence of any install/preinstall/postinstall script or bin, and the .nyc_output/ artifact recording cwd: /home/matteo/repositories/fastq — the direct evidence of the hand publish, which the landed comment infers rather than shows.

No code from this branch is lost, because none of it should land. Nothing else was on it.

[linear-code]

CLOUD-1136 `fastq@1.20.2` lost its provenance upstream, so mise's no-downgrade trust policy refuses the pinned `npm:renovate` and every PR's `ci` job dies in tool install

Why

Every ci job in this repository currently fails before compiling a line, on a pinned tool that has been installing fine for days.

mise ERROR Failed to install npm:renovate@41.173.1: aube install failed: failed to resolve dependencies
  caused by: trust downgrade for fastq@1.20.2 (trustPolicy=no-downgrade):
             earlier published version 1.20.0 had trusted publisher but this version has no trust evidence

Observed 2026-08-29T01:59:59Z on run 33227753755, job ci, head ea83e88 of PR #734. The job died in the mise install step; mise run verify was green on that same head locally, including the whole cargo chain, 2790 tests, the bats suite and policy-test.

This is a property of the world, not of any commit

npm:renovate is pinned at 41.173.1 in mise.toml, and the pin has not moved. What changed is upstream: fastq@1.20.2, a transitive dependency, was published without the provenance metadata its 1.20.0 predecessor carried. mise's no-downgrade trust policy refuses it, correctly — that is the check doing exactly what CLOUD-655's wiring asked of it.

So this is lock-complete versus lock-currency's distinction, arriving from the npm side: a property of the commit belongs in a gate, a property of the world belongs on a clock. Nothing in any branch can be changed to fix it, and every open PR is red for the same reason until it is addressed.

The remedy is a reviewed, version-scoped exemption

Superseded 2026-08-29, and left in place because the reasoning below is where this row went wrong. The section as filed concluded the fix was "reserved for a person" and could not be done here. That misread the mechanism: the trust policy flags the absence of provenance, and the exclusion exists so a review can separate a benign absence from a tampered one. mise's own "Investigating trust downgrades" prescribes exactly that — inspect, determine intent, report upstream, prefer version-scoped exceptions after review — and the evidence is public metadata, not privileged judgement. The review was done, fastq@1.20.2 cleared as a manual publish by the sole maintainer against a real tag, and the exemption shipped in PR #734. See the comments for the evidence table and the corrections.

mise.toml already carries two exclusions of exactly this shape, with a comment stating the policy:

"npm:renovate" = { version = "41.173.1", trust_policy_excludes = [
  "@yarnpkg/core@4.4.4",
  "@yarnpkg/libzip@3.2.2",
] }

these pin the two releases actually reviewed, so the next one is refused again until someone looks. npm.shell_out=true would have switched the whole check off and is not used.

That is the design working: a third exclusion is refused until a human performs the review. Adding fastq@1.20.2 means inspecting the npm release, the source tag/commit, the publisher identity and the tarball, comparing against npmjs.org, and reporting inconsistent evidence upstream — then recording that it was done. An agent adding the exclusion to unblock its own branch would be performing that review by assertion, which is the one thing the comment exists to prevent.

Fixed in PR #734, not filed-and-left: the review below was performed, recorded in this row's comments, and the narrow fastq@1.20.2 exemption landed with it. What remains open is step 3 of the procedure — reporting the provenance gap to mcollina/fastq — plus two findings this exposed that are not this row's fix: the npm:renovate 41→44 bump (blocked behind retiring renovate-config-validator and its suite, since renovate 44 claims the RENOVATE_CONFIG variable the task uses as a path seam), and the unlocked transitive tree.

---

Refinement — Ready

Refinement gate: Definition of Ready & Done. This body carries only specializations.

• Source of truth (§1). The [tools] "npm:renovate" entry in the task manifest stays the one place the pin and its reviewed exclusions live, exactly as it is now. No second list, and specifically not npm.shell_out=true, which switches the whole check off rather than narrowing it.
• Computable predicate (§2). mise install resolves npm:renovate@41.173.1 and exits 0. Decidable by running it; red today.
• Effect (§3). Task-manifest configuration only. No verb, no crate surface, no policy row.
• Output & exit (§5). Unchanged — mise's own.
• Commit / bump (§6). build(deps) or ci(toolchain) — no bump; nothing here is crate source.
• Test obligation (§7). The exclusion is its own discriminator: the install is red before it and green after, which is a real before/after on the one thing that changed. What must NOT be lost is the refusal for every other package — the exclusion is narrowed to fastq@1.20.2, so the next unreviewed downgrade is still refused. A bare fastq entry, or shell_out, would fail that and must not be used.
• Blockers (§8). None, and it blocks everything: no PR in this repository can go green until this is resolved. relatedTo CLOUD-655 (which wired the validator and brought npm:renovate in), CLOUD-656 (the Renovate migration this tool serves).

Acceptance

• A human has inspected fastq@1.20.2's npm release, source tag, publisher identity and tarball against npmjs.org, and the finding is recorded on this row — whether the release is legitimate or genuinely suspect.
• If legitimate: fastq@1.20.2 is added to trust_policy_excludes, narrowly, and mise install is green.
• If not: the finding is reported to the package's maintainer and the repository does not exclude it — the refusal is correct and the tool is pinned back or dropped instead.
• The trust check still refuses an unreviewed downgrade in any other package afterwards, demonstrated rather than assumed.

---

Filed from CLOUD-1030's session, whose PR this blocked. Not fixed here because the remedy is the supply-chain review mise.toml's own comment reserves for a person.

---

Generated by Claude Code

Review in Linear

[coderabbitai]

Warning

Review limit reached

Next included review available in 27 minutes.

View limit details

Limit details: You’ve used the included review currently available.

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Free

Run ID: 9737d019-6e86-498b-85d0-2907c6df1242

📥 Commits

Reviewing files that changed from the base of the PR and between ec2c9c1 and f2fa97e.

📒 Files selected for processing (1)

• mise.toml

---

Note

🎁 Summarized by CodeRabbit Free

Your organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/settings/billing.

_{Comment @coderabbitai help to get the list of available commands.}

[sonarqubecloud]

❌ The last analysis has failed.

See analysis details on SonarQube Cloud