## Bug Description The npm client forwards `Authorization` when it follows a cross-host redirect. Google Cloud Storage rejects a signed-URL request that also presents `Authorization`, so every in-process tarball read fails `401` against any registry that redirects reads to signed object storage. That is the normal production shape, so the suite reports false failures against a correct registry. **Scope is wider than the two hosted rows this was first filed for.** The seeding path reads a tarball back to settle, so this blocks **every** `NeedsUpstream` row on a remote run as well. Measured 2026-09-03 against the npm remote branch: `npm.remote.preflight` skips, and because S08 AC #24 orders it first, the run reports `ErrNothingEstablished` and exits `2` before any other row is attempted. See §Remote-run impact. **Two code paths need fixing, not one.** `GetTarball` is the `dist.tarball` path the hosted rows use. The seeding path does not go through it: it calls `HeadTarball` and `GetTarballAtVettedURL` (`remote_seed.go:130` and `:257`), which share their own `resolveVettedHop` resolver and forward the credential on every hop for the same reason. Those live on the npm remote branch, not on `main`, so a fix limited to `GetTarball` leaves the remote track blocked. Both are needed; see §Suggested Fix. ## Steps to Reproduce Against a registry that redirects tarball reads to signed storage; Artifact Registry staging does. ```shell regconf run --format npm \ --registry-url "https://<ar-host>/<slug>/npm/<repo>/" \ --credential "bearer:env:AR_TOKEN" \ --allow-redirect-host "cdn.artifacts-registry.staging.gitlab-static.net" \ --filter 'npm.tarball.*' --timeout 5m ``` `npm.tarball.integrity-verification` and `npm.tarball.redirect-follow` fail; `npm.tarball.download-url` passes because it reads the URL without fetching it. To see the cause without the suite, publish a package so its object has never been fetched, then make the **first** request to its signed URL carry `Authorization`: ```shell SIGNED=$(curl -sS -o /dev/null -D - --no-location \ -H "Authorization: Bearer $TOKEN" \ "https://<ar-host>/<slug>/npm/<repo>/<fresh-pkg>/-/<fresh-pkg>-1.0.0.tgz" \ | grep -i '^location:' | sed 's/^[Ll]ocation: //' | tr -d '\r') curl -sS -o /dev/null -w 'with auth: %{http_code}\n' -H "Authorization: Bearer $TOKEN" "$SIGNED" curl -sS -o /dev/null -w 'without auth: %{http_code}\n' "$SIGNED" ``` Reproducibility: always. Three consecutive `--filter 'npm.tarball.*'` runs reproduced both failures. Reproduced independently: yes, on Artifact Registry staging 2026-09-02 ## Expected Behavior A tarball read succeeds against a registry that redirects to signed storage, because the signed URL already carries its own authorization. The npm CLI strips `Authorization` on a cross-origin redirect for exactly this reason, and the suite's `npm.install.*` rows, which drive the real CLI, pass against the same objects. ## Actual Behavior ``` FAIL npm.tarball.integrity-verification npm: GET https://cdn.artifacts-registry.staging.gitlab-static.net/...: status 401 FAIL npm.tarball.redirect-follow npm: GET https://cdn.artifacts-registry.staging.gitlab-static.net/...: status 401 ``` The manual probe on a fresh object: ``` with auth: 401 without auth: 200 ``` and the body on the `401`: ```xml <?xml version='1.0' encoding='UTF-8'?><Error><Code>AuthenticationRequired</Code> <Message>Authentication required.</Message></Error> ``` Only one request shape produces `401`, which is what identifies the cause: | Request | Status | |---|---| | full signed query | `200` | | no query at all | `403` | | no query, plus `Authorization` | `401` | | corrupted `Signature` | `403` | A first-hit request carrying `Authorization` is treated as credentialed and the signature is not consulted. Two controls make this conclusive: - `npm.install.exact-version`, `npm.install.semver-range` and `npm.install.dist-tag` all **pass** on the same objects, because they drive the npm CLI, which strips the header. - The URL the suite reported `401` on returns `200` to `curl` two minutes later, so the URL was valid and unexpired; only the request differed. ## Remote-run impact Added 2026-09-03, measured on `sshen/npm-remote-rows-batch` at `a8b0667` against the same staging instance, with a hosted upstream and a remote pointing at it (both created for the run, upstream credentials attached). ```text $ regconf-remote run --format npm --repository-kind remote \ --registry-url https://<ar-host>/<slug>/npm/conformance-npm-remote/ \ --upstream-url https://<ar-host>/<slug>/npm/conformance-npm-upstream/ \ --credential bearer:env:AR_TOKEN --filter 'npm.remote.preflight' SKIP npm.remote.preflight seeding could not establish this row's fixture on the upstream at --upstream-url: the settle's read-back failed with status 401, which further polling cannot recover, so this is not a --settle-timeout shortfall: <?xml version='1.0' encoding='UTF-8'?><Error> <Code>AuthenticationRequired</Code><Message>Authentication required. </Message></Error> Interrupted: <same reason> exit 2 ``` The `AuthenticationRequired` body is GCS's, identical to the hosted-run evidence above. **It is specifically the tarball read, not the packument read.** Worth stating because the obvious first guess is wrong, and chasing it costs time. On a brand-new package published to a fresh upstream: | Read | Authorization forwarded | Authorization dropped | |---|---|---| | packument | `200` | `200` | | tarball | **`401`** | `200` | So the packument path is unaffected either way, and there is no cache-miss dependency on it. The failing read-back is the tarball, which is exactly the path this issue already describes. Consequence for the remote track: the six `NeedsUpstream: true` rows (`preflight`, `packument-relay`, `tarball-url-rewritten`, `tarball-relay`, `dist-tags-relay`, `repeat-read`) cannot seed. The four that need no upstream content (`not-found` and the three `write-refused-*`) would run, but the run aborts at `preflight` before reaching them. ## Suggested Fix **This section is a hypothesis, not a finding.** `pkg/client/npm/tarball.go:78-86` states the current behaviour and its reasoning: S06 pins the SSRF allow-list rather than credential stripping as the control, on the grounds that a hostile registry able to redirect the credential already received it on the first `GET`. That reasoning is sound for SSRF and this is not an argument to weaken the allow-list. The gap is that the same choice also sends the credential to a **benign** redirect target that cannot accept it. Stripping `Authorization` on a cross-host hop costs nothing against the SSRF threat model, since the allow-list remains the control, and it is what every real npm client does. There are two re-issue sites, and both need the same treatment: 1. **`resolveOneRedirect`** (`GetTarball`), the `dist.tarball` path the hosted rows use. Fixed on `main` by [!274](https://gitlab.com/gitlab-org/ops/registry-conformance/-/merge_requests/274). 2. **`resolveVettedHop`** (`GetTarballAtVettedURL` and `HeadTarball`), the path the remote seeding uses. It lives on the npm remote stack, and the fix belongs in [!261](https://gitlab.com/gitlab-org/ops/registry-conformance/-/merge_requests/261) rather than in !263 or !274. `resolveVettedHop` is authored in !261 (commit `6a17a19`, "feat(npm): implement the seven npm client gaps the remote rows need"), !261 targets `main` directly, and !263 stacks on !261. So !261 is what puts the vetted pair on `main`, and fixing it in !263 would leave `main` carrying the defect for the whole window between the two merges. This issue is `AR-Blocks::Closed-Beta` / `priority::1`, so that window is the thing to avoid. One edit covers both functions, since they share the resolver. !274 cannot reach this code, which is not on `main` yet. **The predicate is already on !261, so this does not wait for !274.** Use `conformance.SameOrigin` (`pkg/conformance/validate.go:713`), which `pkg/client/npm/tarball.go` already names in a comment as the confinement the caller is expected to perform, and which `pkg/client/npm/client.go` already has the import for: ```go issuer := c if !conformance.SameOrigin(originalURL, target.String()) { issuer = c.withoutCredential() } ``` It takes two strings, which matches `resolveVettedHop`'s `originalURL string` and `target *url.URL` with no signature change, where !274's `crossHost` takes two `*url.URL` and would need one. It also avoids the fold-alias hole !274's `crossHost` doc describes: that warning is about `strings.EqualFold`, and `normalizeHost` uses `strings.ToLower`, which does not fold the sigma/final-sigma or sharp-s pairs, so `SameOrigin` reports "different origin" for them. That is the fail-closed direction, so no IDNA pass and no `golang.org/x/net` dependency is needed here. **Known consequence, for whoever reviews it.** After !274 lands, `tarball.go` will hold two host predicates that disagree on the port axis: `SameOrigin` treats a non-default port difference as a different origin and drops the credential, while `crossHost` compares hostnames only and keeps it. They answer different questions, confinement to the operator-configured origin versus mirroring what npm and `net/http` do about forwarding a header, so this is not obviously wrong, but it wants either one sentence saying why or a follow-up to unify. Not inside this fix. Verified 2026-09-03 by applying both locally on top of the remote branch: `npm.remote.preflight` goes from `SKIP` with the `401` to `PASS`, and a full remote run executes all 13 rows (4 pass, 9 fail, 0 skip) where before it aborted at row one. The nine failures are all pre-existing and separately tracked, so the fix does what it claims and nothing more. Verified again 2026-09-04 against Artifact Registry staging with both halves applied, addressing the **public** host (`artifact-registry.staging.gitlab.com`): 13 rows, **7 pass / 6 fail**, with all six relay rows passing. The 2026-09-03 figure of 4 pass / 9 fail above was the same build against the Runway host, where three `tarball-*` rows fail on a host mismatch unrelated to this issue. The fix's effect is the same in both; the host choice is what moves the count. `pkg/client/maven` and `pkg/client/oci` need no change. Maven lets `net/http` follow the redirect, and the stdlib already drops `Authorization` on a cross-host hop, which is why Maven passed 31/31 against the same storage backend. OCI has no manual re-issue. This is an S06 spec question as well as a code change: §Operation: Tarball download said the credential travels on every hop, so the amendment and the fix land together (done for `GetTarball` in !274 §Credential scope across the redirect; the vetted pair is covered by the same wording). ## Suggested DRI Conformance tooling, DRI @radbatnag, reviewers @mkhalifa3 and @sylviashen. The `closed-beta.md` workstream table notes that DRI needs re-confirming, so treat it as a suggestion. Unassigned, per triage policy. ## Labels to Apply - `type::bug` - `severity::2` — there is no workaround: the header cannot be disabled by flag, so no in-process tarball read can pass against a registry that redirects to signed storage, and the suite reports a correct registry as failing. Held at `severity::2` rather than raised when the remote-run scope was found, because the rubric grades user impact and nothing is lost or exposed either way; what changed is how much coverage is unavailable, which belongs in the body rather than in the label. - `Category:Artifact Registry` - `artifact-registry::devex` — the closest stream label for validation tooling; none of the `artifact-registry::*` rows describe a defect in a separate repository's client, and `agentic-workflow` is a project label of `gitlab-org/ops/artifact-registry` that does not resolve here. - `backend` - `format::npm`, `repo-type::hosted` - `bug::functional` - No `AR-Blocks::*`: this does not block an Artifact Registry release. It does block using the suite as a release gate for npm tarball reads. ## Additional Context | | | |---|---| | Environment | Artifact Registry staging | | Org slug | `ar-registry` | | Repository | `conformance-npm`, hosted | | Format | npm | | Auth method | token exchange, bearer | | Client and version | `registry-conformance` at `7ca1a6be`; `npm 10.9.2` for the passing control rows | | First observed (UTC) | 2026-09-02 16:33, run ID `fcde277ddc2ebe22` | | Correlation ID | _None from storage; the `401` is a GCS XML error with no request id._ | | Workaround | none known. `--allow-redirect-host` is required to reach the target at all and does not affect the header. | **One way to get a false negative, which cost time here.** Fetching the signed URL anonymously first and then with `Authorization` returns `200` both times, because the anonymous fetch populates the CDN edge and the second request never reaches GCS. Order matters: use a freshly published package for each attempt. **One wrong hypothesis, recorded so it is not re-tested.** The remote-run failure looked like it might be a cache-miss effect on the packument read, which would have made the scope wider still. It is not: a fresh packument reads `200` with the header forwarded, three times in a row. Only the tarball read is affected. Filed as a child of the Artifact Registry closed-beta defect epic because it was found validating that release and it gates npm tarball coverage, but the fix lands in this repository and it is not an Artifact Registry defect.