A virtual repository resolves a tag to the lowest-position upstream that holds it. Nothing on the write side refuses an ordering that places a public remote above internal hosted content, and the audit event on an association change detects such a change rather than preventing it. This work item exists so that the decision about a preventive control is made and recorded, rather than arrived at by nobody making it. Two exposures sit behind that question, and they are at different stages: | Exposure | State | | --- | --- | | Outranking — a hosted upstream and a public remote both hold the tag | **Decided: no write-side control.** See [Decision: outranking](#decision-outranking). | | Sole holder — only one upstream holds the tag, so position decides nothing | **Open.** The one thing left before this item closes. See [Open: sole holder](#open-sole-holder). | Closing this work item records the sole-holder decision, and the closing note is where that record lives: the note names the option chosen and the DRIs who chose it. A bare closure records nothing. It cannot be told apart from nobody having answered, and it would let the status quo ship with this gate's blessing — which matters here because the status quo is itself one of the candidate answers. Until a note in that form is posted the gate is not cleared, whatever this item's state reads. That is its deliverable: a container virtual repository does not reach GA while this item is open. ## The two exposures **Outranking.** Where both an internal hosted upstream and a public remote hold the same tag, the lower position wins. A public remote ordered above internal content therefore decides what the organization pulls for that tag, and resolution cannot detect it because both upstreams answered honestly. Position ordering mitigates this one. **Sole holder.** Where only one upstream holds the tag, position order decides nothing — whoever holds it serves it, from any position. This is the common case on the referrers metadata surface: the referrers `404` falls back to the `<algorithm>-<digest>` tag schema, and an organization that has not attached referrers to a digest has no such tag on its internal upstream, so a public remote serves the referrers for that digest even when correctly ordered below. Attestations and SBOMs are what a client reads from it. Position ordering does not reach this case, and by-digest pull discipline does not either, because the fallback is tag-addressed. ## Decision: outranking **No write-side control.** Upstream position decides, and hosted is not preferred over remote. Virtual resolution keeps the rule it has today: a tag is served by the lowest-position upstream that holds it, hosted or remote. No hosted-first default ordering, no warning on the association request, and no privileged override for placing a remote above a hosted upstream. The order an operator configures is the order the service honors. The audit event on an association change stays as it is, so an ordering change is still visible after the fact. Recorded by @dmeshcharakou, S13 DRI, in [this note](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/792#note_3732477347). Why: this matches GitLab Virtual Registry, which uses the same lowest-position-wins model and leaves the ordering to the operator. Its [documentation](https://gitlab.com/help/user/packages/virtual_registry/_index) lists "position private registries before public ones to prioritize internal packages" as a best practice under upstream-ordering guidance, not as an enforced default, a warning, or an override gate — there is no write-side check anywhere in that surface that refuses or flags a remote placed above a hosted upstream. Artifact Registry's S13 resolution model already matches that posture: the winner is the lowest-position upstream that succeeds, hosted or remote, with no policy preference for hosted content baked into the algorithm itself. A write-side control here would be a deliberate departure from the reference implementation rather than parity with it, and the reference implementation has carried this exposure in production without one. Revisit only if the closed beta surfaces operators getting the ordering wrong in practice, at which point the warning or the privileged-override option is the next step up rather than a reversal of this decision. The candidate answers this chose among, for the record: a hosted-first default ordering, a warning on the association request, a privileged override required to place a remote above a hosted upstream, or no write-side control. ## Open: sole holder Tag-targeted deny patterns covering `sha256-*` are the mechanism that would reach this exposure. Note the constraint — the association endpoints ship rule-less and upstream rule CRUD is not in the closed-beta management surface, so that mechanism is not reachable until a rule-CRUD patch lands. A decision here therefore has to say both what the control is and whether the rule-CRUD work gates GA or the exposure is accepted for the closed beta. The outranking decision does not carry over. It leaves upstream ordering to the operator, and ordering has no effect when only one upstream holds the tag, so nothing in that answer reaches this exposure. ## Who decides The S13 and S17 DRIs together. Lowest-position-wins is S13's model and applies to every virtual slice rather than to container alone; the write surface that would carry any control is S17's. ## Why this is a work item rather than a spec question alone The two other GA gates on container virtual — the realm-host allowlist ([#263](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/263)) and credential encryption at rest ([#417](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/417)) — clear only when work lands, so neither can clear through inattention. A question whose candidate answers include the status quo can, because doing nothing produces one of its answers and leaves no artifact saying it was chosen. Closing this work item is the artifact. Related to https://gitlab.com/gitlab-org/ops/artifact-registry/-/merge_requests/972