A container remote fill by digest is verified, but not until after the blob has committed. The comparison itself is not missing — `RemoteCacheStore.UpsertCacheEntry` refuses a cache row whose committed content address does not match the digest the path named, so a client asking for `sha256:abc` is never served bytes that hash to anything else. What the ordering costs is an orphaned object and a status the spec does not want. Moving the check ahead of the commit is a change to what the fetch helpers ask for, not a handler fix. This issue holds that work. ## Why the check runs late S13's `Fetch` takes a per-request expected digest that reaches `Session.Commit`, so a body disagreeing with the digest the request named can be refused before the blob commits. `RemoteOperations.FetchBlob` and `RemoteOperations.FetchManifest` pass none, so the fill commits on the computed sha256 and `UpsertCacheEntry` compares afterwards, in its `key.byDigest && key.digest != committed` guard. A tag is the other half, and it has no reference value at all. The request names no digest, so the upstream's own `Docker-Content-Digest` is the only thing that can contradict the computed value. The comparison for that one has to run inside the commit as well, which is why an exemption on the forwardable-header allowlist was dropped as unnecessary: no caller reads the header, and the verdict arrives as the fill's error. ## What it costs - **An orphaned object per mismatch.** The blob is in the object store by the time the row is refused, leaving a `blob_storage_blobs` row with nothing attached for [ADR-025](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/main/docs/adr/025_garbage_collection.md)'s `gc:reconcile-scan`, which is Proposed with no merged implementation. - **A laundered contradiction on the tag path.** The origin says the bytes are X, they hash to Y, and Y is stored, served as `Docker-Content-Digest`, and resolvable from then on — so a client pinning Y gets a stable, self-consistent answer with no way to tell it diverged from what the origin claimed. A revalidation sharpens this, because a `200` re-points a tag this cache already holds, so warm tags are covered and not only tags nobody has pulled. Worth stating plainly, because the tag half is easy to over-rate: it does not defend against an active network attacker. Body and header travel in one response, so anyone able to rewrite the bytes rewrites the header too and the comparison passes. TLS is the control there. What this catches is an upstream inconsistent with itself — a CDN serving a stale body under a fresh header, a corrupted mirror object, a TLS-terminating proxy mangling content. ## What has to land together Passing the digest moves the verdict off `oci.ErrCacheFillDigestMismatch` and onto `remote.ErrUpstreamDigestMismatch`. `isRefusedUpstreamContent` lists the first and not the second, so doing the wiring alone regresses the read from the `503` with `Retry-After` that `## Error Cases` requires to a `500`. The two are one change. This is a hazard in the fix rather than a defect in what ships today. ## Scope The by-digest manifest fill and the blob fill both pass a digest; the by-tag manifest fill opts in to the header comparison instead. A fill path may compose `Fetch`, `StandaloneFlow.Deliver` or `Standalone.Serve` and pass the digest through any of them, so the wiring is owed whichever answer the open composition question takes. Container-only. Neither sibling format fetches by digest, and the header comparison runs only on a fetch that opts in, so no Maven or npm fill can be failed by an upstream that emits the header. One trap for whoever takes it. S13's single-flight is keyed by path and a follower inherits the leader's options, so a by-digest fetch that names a digest and one that does not land on the same key, and whichever leads decides whether the fill is verified at all, silently. Every fetch of a by-digest path has to pass the digest once any of them does. Separate `remote.SingleFlight` instances are not an alternative, because that seam wants one instance per remote repository and the mix only arises within one. This is unreachable today — the container remote arms compose no single-flight — and becomes live the moment one is added. ## Relationship to the spec `## Follow-ups` in `docs/specs/S16-container-remote.md` describes this in its "Container by-digest fills move onto `FetchOptions.ExpectedDigest`" entry, which is the only entry in that section carrying no tracking pointer; it owes a `Tracked in` line pointing here. The neighbouring "`Docker-Content-Digest` readable, with a pre-commit comparison" entry is stale on a related point: it still asks for the allowlist exemption, which [#433](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/433) has since dropped as unnecessary. Both are spec-text edits rather than work here. S16 marks the affected criterion **gated**, and the change that closes this removes the marker. Two tests are written and skipped against it, each with arrange, act and assertions in place, the skip between the act and the assertions, and a `Fatalf` above the skip that fails the moment the arm starts refusing these bytes — so lifting the gate is a one-line deletion in each: - `TestRemoteManifestServe_TagMiss_DisagreeingUpstreamDigestHeaderIsNeverCached` - `TestRemoteManifestRevalidate_DisagreeingUpstreamDigestHeaderIsNeverCached` ## Relationship to #433 [#433](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/433) owns the S13 seam and says twice that the container-side wiring is out of its scope. Its gap 1 lands `remote.FetchOptions.ExpectedDigest`; its gap 2 lands the pre-commit comparison through [!1807](https://gitlab.com/gitlab-org/ops/artifact-registry/-/merge_requests/1807), which plumbs a cross-check argument through `RemoteOperations.FetchManifest` and has the container fetch pass `false` — its own tests assert that. So the seam arrives complete and switched off, and switching it on is this issue. Raised in review of !1875.