nordisk/holger

holger-file-oci-repository — crate card

Reverse-engineered (from source — verify, don't trust the name)

• One-line pitch: Disk-backed, writable OCI registry (Distribution Spec v2) — holger's push target for the modern Helm OCI flow and any OCI artifact.
• Does: Implements RepositoryBackendTrait with the full v2 write + read surface: version probe, manifest GET/HEAD by tag/digest, blob GET/HEAD, tag listing, blob upload (monolithic + chunked PATCH/PUT), manifest PUT. Content-addressed on-disk layout ({base}/blobs/sha256/{hex}, uploads/{id}, manifests/{image}/tags/{tag} + /sha256/{hex}) with blobs shared across images. Treats every blob as opaque bytes — never decompresses/parses uploads, removing that attack surface. Replaces the bespoke ChartMuseum HTTP API. Path-component checks mirror file-rust.
• Key deps: traits, std fs/io — a disk backend, not znippy-backed.
• Shape: lib, single lib.rs. One of the two file-* (mutable/disk) backends.
• Observed role in the workspace: Registered in server-lib as repository-file-oci; the helm push oci://… / helm pull target. Complements the read-only znippy Docker/Helm backends.

Fill in (one line each — only the human knows these)

• Primary consumer(s):
• Why it exists (vs the obvious alternative):
• Hard constraint (airgap / no-C-deps / no-FFI / pure-Rust / etc.):
• Release cadence & independence (rides a parent? own repo someday?):
• Status (production / prototype / experimental / stubbed):
• Must-NOT-change invariant:
• Biggest known gap or TODO:
• Anything a newcomer would get wrong about it: