fix: two reachable panics + two OCI image digest nondeterminisms - #1105

Four small independent fixes: two reachable panics and two sources of OCI image digest instability. None of them change BuildSpec, the spec-hash encoding, or any cache key — behavior only changes on inputs that previously crashed, and for OCI images whose digests were previously unstable between identical runs.

1. mfile: empty exec string panicked the task parser

Task::exec_and_args tokenized a task's exec string with shlex and called .next().unwrap() on the token stream. An exec that is empty, whitespace-only, or otherwise yields no tokens has no first token, so minimal panicked on a malformed-but-easy-to-write minimal.toml:

[tasks.oops]
exec = ""

The list form already handles this case: exec = [] resolves to ("", []) and fails downstream with a real error. The fix makes the string form take the same path. Regression test included (exec_str_empty_does_not_panic).

2. lcache: special files in a cache directory panicked the walker

lcache's DirEntry::file_type classified entries as File or Dir and hit unreachable!() for anything else. But the local cache directory is ordinary host filesystem — a stray symlink, socket, or fifo (leftover tooling, a curious user, a crashed process) is entirely reachable, and one such entry made any cache walk panic. Added a FileType::Other variant so walks classify these instead of crashing. The cache itself never creates such entries; this only makes foreign ones survivable. No callers matched exhaustively on the enum, so no behavior changes for File/Dir.

3. op: OCI image layer order depended on thread scheduling

Image layers are built in parallel under a rayon::scope, and each worker pushed its finished layer into a shared Vec — i.e. layers landed in completion order, which varies run to run with thread scheduling. Layer order is part of the OCI manifest, and the manifest digest is the image digest, so two builds of the identical graph could produce different image digests. Workers now tag results with their dependency index and the results are sorted back into dependency order before manifest assembly — same layers, same content, stable order.

4. op: OCI config env order depended on HashMap iteration

The image config's env list was built by iterating a HashMap directly. Rust's HashMap iteration order is randomized per process, so the config blob — and with it the image digest — differed between identical builds. The vars are now sorted by key before serialization.

Why 3 and 4 matter beyond tidiness

These made op's OCI output non-reproducible even for perfectly reproducible inputs: the same graph, same artifacts, same everything produced a different image digest each run. Anything that wants to compare, cache, sign, or attest image digests needs digest stability first. (Because the previous digests were unstable, nothing could have validly pinned one — so stabilizing them breaks no existing expectation.)

Provenance

All four were findings of the formal-verification readiness audit of minimal's pure cores (write-up circulating separately); they are its "phase 0" — fixes that stand on their own regardless of any decision about that effort.

🤖 Generated with Claude Code