[bonk-ai]

What and why

zip 8.6.0 to 9.0.3 for microvms-app, whose image build writes its artifact with ZipWriter, and for microvms-core, whose BDD tests read that artifact back (a dev-dependency there). This supersedes Dependabot's #608, which moved the requirements to 9.0.1 and failed to compile. The branch started from main at 675ebef (#618) and merged main again at 6ffb9c8 after #621.

The source change

zip 9 converts an entry's file name on demand (zip-rs/zip2#807), so an entry's name() and the items of ZipArchive::file_names() return Result<Cow<str>, ZipError> where 8.6 returned &str. Only test code reads names:

• four sites in crates/microvms-app/src/control/artifact.rs's tests module, and crates/microvms-core/tests/bdd_ensure.rs:436, now call .expect("a name").into_owned();
• the IMAGE-7 test reads each name once into a local and uses it in its date and mode assertions, which used to call entry.name() again.

The code that builds the artifact (artifact.rs:185-255) only writes, through ZipWriter::start_file, SimpleFileOptions, CompressionMethod::Deflated, DateTime::default() and System::Unix, and it compiles unchanged. ensure.rs and image.rs open archives only in their tests, with len() and by_name(), which kept their signatures.

The comment on microvms-app's zip requirement no longer says the crate is pinned to 8.x because "9.0 exists only as 9.0.0-pre2" (9.0.0 shipped on 2026-10-09), and it now lists the project and build-context files the artifact carries besides the binary and the Dockerfile.

The artifact bytes

The image name hashes the build's inputs, not these bytes (artifact.rs:169-173), and byte identity is what keeps one object under each content-addressed S3 key. A probe test built the same artifact (a stub aarch64 daemon and a FROM scratch Dockerfile) on main and on this branch: both are 244 bytes with sha256 9d2fff9aeceb7f07d3129f7a2046d57041fb5a1eb89ea199e425c7f54ff60f37. The probe was removed before the commit. It covers one input. zip's deflate feature turns on the same encoders in 8.6.0 and 9.0.3 (deflate-zopfli and deflate-flate2-zlib-rs), and both lockfiles hold flate2 1.1.10, so larger inputs should compress to the same bytes too; that is inferred from the two manifests, not measured.

Windows

zip 9 reads an entry's mode differently when the entry records MS-DOS as the host that made it: zip 8.6.0 returned the stored Unix mode whenever the high 16 bits of the external attributes were set, and zip 9's get_unix_mode ignores them and returns 0o100664. The writer records the running host, so on Windows every entry recorded MS-DOS, and this branch's first CI run failed lint, model, and test tiers (windows-latest): the_daemon_entry_carries_the_execute_bit read the daemon as 100664 and the_artifact_is_deterministic_with_fixed_dates_and_modes read the Dockerfile as 664. #621 (merged as 6ffb9c8) makes the writer record Unix on every host, and this branch merged main after it.

Lockfile

cargo update -p zip moved zip alone, 8.6.0 to 9.0.3, and gave it a dependency on nix 0.31.3, which the lockfile already holds. No crate was added or removed, and crates/agentd/fuzz/Cargo.lock holds no zip.

Release check

zip 9.0.0, 9.0.1 and 9.0.3 were published through crates.io trusted publishing from zip-rs/zip2, 9.0.2 by Pr0methean, a maintainer, and none is yanked (crates.io, read 2026-10-14). The 9.0.x changelog (read 2026-10-14) lists read-side fixes (extraction of symlinks and permissions, the legacy decoders, ZIP64 parsing) and one write-side fix for ZIP64 central fields; the artifact's entries are far below the 4 GiB at which zip writes ZIP64 fields.

Evidence

• mise run check, run bare on this tree: EXIT=0 in 425 s, 69 test result: lines, 1818 passed, 0 failed, [security] advisories ok, bans ok, licenses ok, sources ok, prose:check 0 errors, and changelog:check "1 shipped files change, with changelog.d/608.internal.md".
• Probe test on main 279f28f (zip 8.6.0) and on this branch (zip 9.0.3): the same 244 bytes and sha256 for the same inputs.
• The merged tree (this branch plus main at 6ffb9c8), on Linux: cargo test -p microvms-app --lib -- control:: 309 passed, 0 failed; cargo clippy -p microvms-app --all-targets -- -D warnings EXIT=0; mise run guards:fire -- --only app-artifact-records-dos-as-its-host "1 of 1 fired" under zip 9. The Windows tier runs in this PR's CI.
• ./tools/changelog.py check: "4 fragments in changelog.d/, and they build".
• mise run pr-body:check -- --body <this body>: EXIT=0.
• Live conformance run: not run on this tree.

Parity

• No public name changed on any surface (core, CLI commands, microvms.pyi, index.d.ts).

Guards

None: this adds no guard. The artifact tests in artifact.rs (IMAGE-7 among them) already read back every entry's name, date and mode, and they pass on zip 9.

Follow-ups

• A live conformance run on main after this merges builds real images from this artifact.

Platform claims

• Not applicable: this changes no claim about AWS behavior.

Scope

• This is not an orchestrator or a fork implementation
  (see docs/STRATEGY.md).