feat(distro): accept digest-pinned OCI references

Docker pulls ubuntu@sha256:... and repo:tag@sha256:...; ecrou
errored on the '@'. parse_oci_ref now peels the pin (which contains
the reference's only legal post-slash colon), validates it as
algo:hex, and the manifest is fetched by digest - the tag, when
co-present, is ignored the way docker ignores it. Pinned
references are immutable by definition: the :latest freshness
check skips them, and the cache filename carries the pin so a
tagged ref and its pin never share an entry. Pull parameters
gather into registry::OciPull.
This commit is contained in:
vhaudiquet committed 2026-10-30 00:08:27 +01:00
1 parent 200aac1f89
commit 28f24abb6f
5 files changed
+217 -43

No files matched your search

+9 -7
View File
@@ -299,10 +299,12 @@ ecrou probe
```
The image is a distro name (`alpine`, `ubuntu:noble`), an OCI
reference (`ghcr.io/org/image:tag`), or a local rootfs archive named
with a path (`./rootfs.tar.gz`, `/tmp/rootfs.tar`): a path reference is
read in place on every run, never downloaded and never cached as a
pristine entry.
reference (`ghcr.io/org/image:tag`, `ubuntu@sha256:…`,
`repo:tag@sha256:…` — the digest wins over a co-present tag, as in
docker), or a local rootfs archive named with a path
(`./rootfs.tar.gz`, `/tmp/rootfs.tar`): a path reference is read in
place on every run, never downloaded and never cached as a pristine
entry.
| Flag | Default | Description |
|------|---------|-------------|
@@ -394,9 +396,9 @@ stop:
hard-failing. That is a deliberate trade, not an oversight.
- The cache trusts its own entries. Once written, an entry is never
re-verified, except OCI `:latest` tags, which are re-checked against
the registry digest on every run. Pinned tags and distro tarballs are
assumed immutable; `--no-cache` and the digest-changed path are the
escape hatches.
the registry digest on every run. Digest pins, pinned tags and
distro tarballs are assumed immutable; `--no-cache` and the
digest-changed path are the escape hatches.
- Concurrent runs of the same image are safe, not efficient: each
writes its own partial file and the last atomic rename wins, so two
racers download twice rather than corrupt anything.