the crates.io token exchange sends no user-agent and dies as a policy 403: name the org in every registry curl

[CarlAllenn]

Defect

edtf v1.3.2's registry legs failed three consecutive times (run
32681747423 + two re-runs) and the cause is the canon's, not the
repository's. Measured 2026-08-24 by a claims probe on an edtf branch
(runs 32684527127, 32684570428, 32684599155 — branch oidc-probe,
deleted after):

• GitHub's OIDC mint is HTTP 200 with complete, correct claims
  (repository monumental-archive/edtf, environment publish,
  ID-stamped immutable sub) — the failure is registry-side.
• publish-rust-crate.yml's exchange curl (line ~109) sends no
  meaningful User-Agent, and crates.io's protection layer 403s it with
  the data-access-policy boilerplate — a misleading, unattributed
  refusal that reads like a trust mismatch. With a User-Agent naming
  the org, the same exchange proceeds to real validation and answers
  HTTP 400 naming the probe's wrong filename and listing the FIVE
  configured publish.yml publishers — i.e. the repository's
  trusted-publishing config is correct and complete, and the header is
  the entire crates-side defect.
• The npm leg fails ENEEDAUTH in the same runs. Boundary measured:
  the mint works (above), release-lab published npm 2026-08-21 through
  the identical workflow, and the package's trusted publisher was
  re-verified during the failures. The one measured delta: edtf pins
  node = "26.5.1", the lab pins 24.19.0 — the bundled npm differs,
  and npm's OIDC trusted publishing is npm-version-sensitive. Unproven;
  the build pins it by measurement.

Consequence recorded: v1.3.2's crates/npm legs are unreachable at that
tag forever (the tag's tree pins canon v1.60.0), so v1.3.2 is a partial
burn — GitHub release published with full evidence, registries not.
edtf's next release after the pin bump completes the arrival.

Decided build

Decided 2026-08-24, from the probe:

• the crates exchange curl gains
  User-Agent: monumental-archive-publish (https://github.com/monumental-archive/.github)
  — an org-identifying UA per crates.io's own data-access policy, with a
  comment quoting the boilerplate 403 so the next reader recognises the
  block if the policy tightens again.
• sweep every curl in the publish/release workflows and release/
  scripts that targets a third-party registry (crates.io, npmjs, zenodo)
  for the same gap; GitHub-API curls keep their existing shape.
• the npm leg: measure npm at node 26.5.1 vs 24.19.0 for OIDC trusted
  publishing (the CLI's own debug log names the step); fix belt-side if
  it is a canon assumption, or file the edtf pin correction if it is the
  repo's node pin — whichever the measurement says. Do not ship a token
  fallback: the workflow's deliberate ENEEDAUTH-over-weaker-auth stance
  stays.

Rejected, recorded: emailing crates.io for an allowlist (the header is
the documented contract); retrying v1.3.2 (the tag's pin cannot see any
fix by construction).

Canon consequence

Release-path change: rides the next canon release, no lab leg (standing
ruling — and the lab could never have caught this: rust-crate is not in
the lab's class list, the paths-proven-only-by-real-repos family). Every
consumer's registry legs inherit the header at their pin bump.

Done when

• the probe's two-request pair quoted in the PR: UA-less → 403
  boilerplate; org UA → 400/200 with real validation prose
• edtf's first release after its pin bump reaches BOTH registries green
  — run linked here (this is also the rust-crate class declares a planned SBOM obligation with no producer: emit the plan and lint the declaration/producer join #833/batch 2026-08-21 status: where the import batch stopped and what picks up #834's completing evidence)
• the npm measurement recorded here with the CLI debug-log line naming
  the failing step, and its fix landed wherever the measurement points
• mise run ci green on the commit

Sequencing

Immediate — it blocks edtf's arrival on both registries. Canon release
after merge; edtf pin bump; edtf release next. Refs #833, #834,
release-lab#262 (proof ledger).

[CarlAllenn]

crates half built (#910). The npm half's stated cause is FALSIFIED.

crates: reproduced independently, not quoted

I re-ran the pair myself with a deliberately invalid JWT, so the header is the only difference between the two requests and neither can be confused with a config problem:

UA-less : HTTP 403  "We are unable to process your request at this time. This
                     usually means that you are in violation of our API data
                     access policy (https://crates.io/data-access) ..."
org UA  : HTTP 400  "Failed to decode JWT"

The 400 is the evidence: with the header the request reaches real validation and objects to the thing that is actually wrong. Done-when item 1 satisfied.

Sweep, with the claim bounded by measurement — only the crates.io API host enforces this today:

host	UA-less	org UA
crates.io (API)	403	200
static.crates.io	200	200
registry.npmjs.org	200	200
zenodo.org (API)	200	200

All four now send the header; three are insurance rather than repairs, and each site says which it is. Saying so matters: without it the next reader assumes four live breaks were fixed and mis-weights the next 403.

npm: the node-pin hypothesis does not survive measurement

The Decided build says edtf's node = "26.5.1" and the lab's 24.19.0 bundle different npm versions. They do not. Both bundle npm 11.17.0 — read from each install's own lib/node_modules/npm/package.json rather than from a npm --version that could have resolved a different npm on PATH:

node 26.5.1  -> lib/node_modules/npm/package.json : 11.17.0
node 24.19.0 -> lib/node_modules/npm/package.json : 11.17.0

So there is no version delta between edtf and release-lab, nothing to bump, and the "unproven; the build pins it by measurement" clause resolves to: the premise is wrong, not to a pin correction.

The failing run agrees. npm 11.17.0 (well past the workflow's own >= 11.5.1 guard, which passed) packed the tarball and printed the full notice block, then:

npm error code ENEEDAUTH
npm error need auth This command requires you to be logged in to https://registry.npmjs.org/

It never attempted an OIDC exchange. Checked and ruled out on the way past: the canon's publish job declares id-token: write and environment: publish, and edtf's caller grants id-token: write in its union — so this is not the startup-failure permissions shape either.

What blocks the next step, and the decision I am not making alone

Done-when asks for "the CLI debug-log line naming the failing step". That line is not obtainable from the completed runs: npm writes it to /home/runner/.npm/_logs/…-debug-0.log on the runner, and the job surfaces nothing from there. Every re-run so far has therefore been blind, which is why three of them told us nothing.

Two ways to make the next run diagnostic, and I have built neither, because both change the release path and the choice is a real one:

1. Assert the OIDC endpoint is present before publishing — a two-line guard checking ACTIONS_ID_TOKEN_REQUEST_URL/_TOKEN are non-empty and failing with a named message if not. Leaks nothing, and settles the top remaining hypothesis (does the runner inject the OIDC endpoint into this job at all) definitively.
2. Surface npm's own debug log on failure. Names the step directly, which is what Done-when wants — but it prints a log written by a third-party CLI on an authenticated path, so it wants a deliberate decision about what could land in a public log rather than my judgement in passing.

My recommendation is (1) first: it is cheap, leaks nothing, and if the OIDC variables turn out to be absent it explains ENEEDAUTH completely and (2) becomes unnecessary. If they are present, (2) is justified and better targeted.

No token fallback is proposed either way — the ENEEDAUTH-over-weaker-auth stance stands.

[CarlAllenn]

npm root cause MEASURED (run 32681747423, npm-leg attempt 3, notice block): the tarball is @monumental-archive/edtf-wasm@1.3.2 — the package was renamed to the org SCOPE at import — while the trusted publisher is configured on the old unscoped edtf-wasm (which holds v1.2.3). npm 11.17.0 found no trusted-publisher config for the scoped name, so it never attempted OIDC and fell to ENEEDAUTH. Independently corroborated by the @monumental-archive scope 404ing on npm (the org does not exist there yet).

So the npm half is REGISTRY-SIDE SETUP, not canon code: (1) create the npm org monumental-archive; (2) trusted publisher for the scoped package (pre-configured if npm allows it for new packages, else a one-time revoked-after bootstrap for the first scoped publish). Owner action (Carl), recorded here; the #914 diagnostics remain correct and will name exactly this on any future miss. The canon-side build of this issue is complete with #910 + #914.

[CarlAllenn]

npm epilogue: the root cause is a package identity split, and it is registry-side

Re-measured against the registry API with the org UA, 2026-08-24. Two packages exist, and that is the answer:

package	versions	last publish
edtf-wasm (unscoped, the old line)	0.2.0 … 1.2.3	2026-08-08
@monumental-archive/edtf-wasm (scoped)	1.2.3 only	2026-08-21

The workflow publishes the scoped package (npm-scope: monumental-archive), and the trusted-publisher configuration is on the unscoped one — right repository, right workflow filename, wrong package. npm therefore finds no trusted publisher for the package it is actually publishing, never attempts an OIDC exchange, and falls through to ENEEDAUTH.

That is consistent with every measurement in this thread and explains why none of them found anything wrong: npm 11.17.0 is well past the guard, id-token: write is granted at every link in the chain, and environment: publish resolves. Nothing on our side was misconfigured — the config is on a neighbouring package.

One correction to the correction, so the record is exactly true

The 404 in my earlier note was not a measurement of the real scope and does not need retracting. It was @monumental-archive-nonexistent/probe — a deliberately non-existent scope I used precisely so a local npm publish could not possibly publish anything — and it is genuinely absent (re-confirmed 404 just now). Separately, and in the same note, I measured the real scoped package at 1.2.3, which is the same figure quoted above.

What I had not done is look for an unscoped package of the same name. That is the genuinely new fact, and it is the one that cracks it. The gap in my work was a missing query, not a wrong reading.

What this says about the two diagnostics in #914, precisely

They are not interchangeable here, and the distinction is worth keeping:

• The OIDC-vars assertion would NOT have caught this. The variables are present; the runner offered trusted publishing correctly. It would have passed and the run would still have died ENEEDAUTH.
• The masked debug log WOULD have. npm's own log records the trusted-publisher lookup and its result, which is the step that fails here — and that log is exactly what three blind re-runs could not see.

So the value delivered is (2), and (1) remains worth having for the different failure it names — a caller that forgets id-token: write, which is a real and separate way to reach the same ENEEDAUTH with the opposite cause. Keeping both means the next occurrence is distinguishable on sight rather than by another round of elimination.