nordisk/holger

holger-znippy-package-repository — crate card

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

• One-line pitch: znippy-archive-backed repository that serves znippy packages themselves — the one format that is znippy all the way down.
• Does: ZnippyRepoZnippy implements RepositoryBackendTrait. Unlike every other backend (which use a znippy archive as a backing store for a foreign ecosystem), this serves znippy's own native .znippy packages (merged/signed, produced by the znippy CLI) as the artifact, over a small Holger-native HTTP surface: GET /{repo}/ (newline list of packages), GET /{repo}/{name}/{version} ({name}-{version}.znippy), GET /{repo}/{path} (path-passthrough). Optional provenance: with the sign feature, with_archive_verified verifies the backing archive's detached-CMS signatures against trusted roots and records verified_signer (Some(common_name)); off by default (matches znippy's opt-in sign philosophy).
• Key deps: traits, znippy-common (ZnippyArchive/ZnippyReader; sign feature enables znippy-common/sign), anyhow.
• Shape: lib, single lib.rs. Features: sign (provenance verification, off by default so the default dep graph doesn't require znippy-common/sign — matters for transitive consumers resolving znippy from crates.io), testmatrix.
• Observed role in the workspace: Registered in server-lib as repository-znippy-package; server-lib's own sign feature forwards to this crate's sign, which the server-cli enables so ron_trusted_roots-configured repos verify provenance before serving.

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: