Module module 

Pinned third-party .modl module artifacts (Phase 15) — the registry seam (ModuleSpec, spec_for) and the on-disk cache (cache_root, module_cache_dir, cached_entry) that fetch verifies into.

Security boundary (read this before touching fetch.rs): the sha256 check this module performs proves ONE thing — that the bytes on disk are byte-for-byte what the release feed currently serves for a given digest. It does NOT prove the module is validly signed by its author, and it is not a substitute for one. Ignition’s own module-scan owns the signature check, at gateway load time, entirely outside ign’s control. An attacker who can both upload a malicious .modl AND control what digest the feed reports for it defeats this check by construction — that supply-chain trust boundary is accepted, not mitigated, here (see the phase’s threat register, T-15-07).

Modules

fetch

Release resolution, streamed download, and atomic cache-verify for third-party .modl module artifacts (Phase 15, RMOD-02/03).

Structs

CachedArtifact

A verified artifact already sitting in the cache.

ModuleSpec

One third-party module’s release-feed coordinates: where its releases live (repo) and how a version string becomes a release tag / asset filename (tag_template / asset_template, both substituting the literal token {version}).

Constants

GIT_MODULE

The ignition-git-module release feed (live-verified shape in 15-RESEARCH.md: tag v{version}, asset Git-{version}-signed.modl).

MODULES

The module registry — TWO entries as of Phase 16, Plan 02: GIT_MODULE (Phase 15) and PROJECT_SCAN_ENDPOINT, registered through the identical seam to prove the registry abstraction holds (SC-5) rather than merely asserting it. A third module registers here the same way; nothing else in the provisioning path should ever need to change for it.

PROJECT_SCAN_ENDPOINT

The ignition-project-scan-endpoint release feed (Phase 16, 16-02-PLAN.md — verified live this session, not re-derived): bw-design-group/ignition-project-scan-endpoint, release v1.0.0, asset Project-Scan-Endpoint.modl (30,150 bytes, sha256 f0ffb9cf90f0dfb55647080399c4699a32d6ded0387e0142b7c1cb6212806722), signed (the release archive carries certificates.p7b and signatures.properties).

Functions

cache_root

The module artifact cache root: IGNITION_CLI_CACHE env override first, else the platform cache dir (directories::ProjectDirs:: from("", "", "ignition-cli").cache_dir()) — mirrors crate::config::config_path’s IGNITION_CLI_CONFIG shape exactly, including its expect on a missing home directory. The env override is what lets tests point at a tempfile::TempDir instead of the developer’s real cache.

cached_entry

Look up a cached, verified artifact for module_id/version — keyed by VERSION ALONE (D-08): a hit never needs the feed, which is what makes SC-3 (no network on a repeat fetch) and SC-4 (offline-with-cache succeeds) possible. Accepts only filenames that strip to EXACTLY <version>- + 64 lowercase hex + .modl — no regex, just strip_prefix/strip_suffix plus a length + hex-digit check, which also disambiguates a prerelease version whose own string contains a hyphen (e.g. 2.3.4-rc1 never satisfies the fixed-length digest check when only 2.3.4 was requested).

module_cache_dir

The per-module cache directory: <root>/modules/<module_id>.

spec_for

Look up a registered module by ModuleSpec::id.

validate_module_id

Validate a module id string the same way (T-15-03): 1–32 characters from [a-z0-9-]. Exit 2 invalid_input.

validate_version

Validate a module version string BEFORE it becomes a filesystem path segment or URL component (ASVS V5, T-15-03): 1–64 characters from [A-Za-z0-9._+-], with no .. window anywhere (path-traversal refusal — this also catches a lone ..). Exit 2 invalid_input — a caller-supplied bad value is the usage class, so no new slug is warranted (the frozen taxonomy’s existing precedent).