## Bug Description The publish walker refuses a hosted npm publish with `--provenance`: `400`, `code: publish_envelope_invalid`. The envelope carries two `_attachments` entries, the tarball and the `{name}-{version}.sigstore` bundle, and the walker admits exactly one. A CI job configured for provenance fails on this registry and succeeds on the GitLab Package Registry, which drops the bundle. Neither registry stores the attestation, so `dist.attestations` is absent from every packument this one serves. ## Steps to Reproduce 1. Create a hosted npm repository and point `.npmrc` or `.yarnrc.yml` at it, with a package ready to publish. 2. In a GitLab CI job with `id_tokens: SIGSTORE_ID_TOKEN: aud: sigstore`, run `npm publish --provenance --access public` or `yarn npm publish --provenance`. npm needs `--access public` because it probes `GET /-/package/{name}/visibility` first and stops client-side when the registry has no such route. yarn does no probe. 3. Without CI, send the envelope by hand: `PUT /{slug}/npm/{repository}/{package}` whose `_attachments` carries `{name}-{version}.tgz` first and `{name}-{version}.sigstore` second, the second with `content_type` set to a sigstore bundle media type and `data` holding a JSON string. Reproducibility: always Reproduced independently: not attempted. The walker's second-key abort in `internal/format/npm/streampub/attachment.go` and the row `e2e.npm.publish.reject-two-attachments` in `docs/testing/e2e/npm.md` pin the refusal, and the row names both provenance flows as the clients that send a second entry. ## Expected Behavior The registry admits the publish, verifies the bundle against the tarball's `sha512` subject, stores it against the version, and serves it the way the npm public registry does. The packument's `versions[{ver}].dist.attestations` carries `{ "url": ".../-/npm/v1/attestations/{name}@{version}", "provenance": { "predicateType": "https://slsa.dev/provenance/v1" } }`, and `GET /-/npm/v1/attestations/{name}@{version}` returns `{ "attestations": [ { "predicateType": "...", "bundle": <sigstore bundle> } ] }`. ## Actual Behavior `400` with `code: publish_envelope_invalid` at the second `_attachments` key, before its value is read. The registry writes no version and no blob row, and cancels the upload session opened for the tarball. The refusal dates from 2026-09-03, when the one-entry rule merged in gitlab-org/ops/artifact-registry!2228+s. Before that the walker never read a second entry, so it admitted the publish and dropped the bundle. _Response body not captured. A CI run against a deployed instance can supply the exact body._ ## Suggested Fix **This section is a hypothesis, not a finding.** Both clients build the tarball entry first and append the bundle second (npm 11.19.0 `libnpmpublish/lib/publish.js`, yarn berry `packages/plugin-npm/sources/npmPublishUtils.ts`), so `readAttachments` keeps streaming the first entry and reads one named key after it, and `validateShape` checks that key beside the tarball key because yarn sends `name` and the version after `_attachments`. The bundle's `data` is a JSON string, so the walker can read it whole under an explicit size bound rather than stream it. Storage needs a row against the version, verification of the bundle's subject digest against the tarball's `sha512` before the write, `dist.attestations` on the packument render, and the attestations endpoint. The plan may land the admit step first, dropping the bundle with an `npm-notice` response header that says it was not stored, since the npm CLI prints that header on every response. S11 says which behavior the registry has at each step. ## Suggested DRI S11 npm hosted, @dmeshcharakou per the workstream assignments table in `docs/roadmap/closed-beta.md`. The fix lands in the hosted publish walker and the packument render, not in the remote or virtual tiers. @hswimelar owns the one-entry rule and the beta decision in gitlab-org/ops/artifact-registry#1156+s. ## Labels to Apply - `type::bug` - `AR-Blocks::GA`: beta users have a workaround they can live with, publishing without `--provenance`, which is the tested main path. It does not gate closed beta. The beta keeps the refusal, decided in gitlab-org/ops/artifact-registry#1156+s. It gates GA because the Package Registry accepts this publish and GitLab CI issues the `SIGSTORE_ID_TOKEN` it needs, so a GA registry that refuses it regresses anyone moving over. - `priority::1`: missing implementation. The registry has no attestation storage, no bundle verification, and no attestations endpoint. - `Category:Artifact Registry` - `artifact-registry::formats` - `format::npm` - `repo-type::hosted` - `backend` ## Additional Context | | | |---|---| | Environment | any build from 2026-09-03 on, after gitlab-org/ops/artifact-registry!2228+s | | Org slug | n/a | | Repository | any hosted npm repository | | Format | npm | | Auth method | any | | Client and version | `npm 11.19.0` (libnpmpublish 11), `yarn 4.18` | | First observed (UTC) | 2026-09-03, in the review of gitlab-org/ops/artifact-registry!2228+s | | Correlation ID | none | | Workaround | drop the `--provenance` flag or set `provenance=false`. It is the publish path the e2e catalog and the yarn recipe exercise. It drops the attestation rather than storing it, so it does not satisfy a policy that mandates provenance. | Both clients set `content_type` to the bundle's `mediaType`, `data` to the bundle as a JSON string rather than base64, and `length` to its byte count. npm generates the bundle only inside GitHub Actions or GitLab CI, so a local reproduction needs a CI job against a reachable instance, `npm publish --provenance-file` with a bundle for that exact tarball, or a hand-built envelope. The walker's token bounds are depth and per-object key count, so the envelope cap alone bounds a skipped scalar's size. PyPI attestations (PEP 740) are a separate item, gitlab-org/ops/artifact-registry#363+s.