GeezerVison

Problem

Hosted Maven merged into .mvn/checksums/checksums.sha256 by splitting every line on two spaces, rebuilding the file from that map, and silently dropping any line it couldn't split that way. That deleted a user's single-space line, a * (binary marker) line, a tab-separated line, comments and stray text. It also rewrote a CRLF file as LF and re-sorted every line.

The file and the .mvn/maven.config settings were read five different ways (discovery, the hosted merge, the hosted drop filter, the unenforced-pin warning, the upstream unwind), and each judged differently whether Maven enforces the file.

Change

One pure module, formats::maven::trusted_checksums (no I/O, no host policy), used by all five sites.

• Reading the checksums file (parse_line, entries): tolerant. It accepts what sha256sum-style tools write: one or more spaces or tabs, an optional *, CRLF, blanks around the line. # lines are comments. The first field doesn't have to be a valid hash, so a line for a path hosted mode owns is recognised whatever its hash. Each entry records maven_reads: true only for the exact <64 lowercase hex> <path> shape that maven-resolver's SummaryFileTrustedChecksumsSource checks. Maven splits on exactly two spaces, doesn't strip *, and compares against its own lowercase digest.
• pinned: path → hash for the lines Maven checks. A later line for the same path wins.
• edit:
  • Owned paths are rewritten in place in canonical form, keeping that line's ending, and collapsed to one line.
  • Dropped paths are removed whatever their hash.
  • Missing owned paths are inserted before the first later checksum line that sorts after them, ahead of the comment block directly above that line, or appended. New lines use the file's dominant line ending.
  • Every other line is kept byte for byte.
• config_enforces: the one rule, documented in the code. maven.config is read the way Maven 3.9+ reads it, one argument per line (maven_config_line_properties, split out of maven_config_properties). It then requires every setting Maven reads this file by, judged with the resolver's defaults: post-processor on, checksumAlgorithms naming SHA-256, summary-file source on, basedir at .mvn/checksums, originAware off.
• enforced: config_enforces plus the Maven Wrapper rule hosted already warned on. An Apache Maven older than 3.9.4 ignores the files; no wrapper, or another distribution, counts as enforcing.
• CONFIG_ARGS: the maven.config lines hosted writes. They and the keys read are built from one literal per settings prefix.

How each site uses it:

Golden change: in redirect-maven.json, mvn-config-merge/expected goes from locked_integrity: Sha256Hex(ccc…) to null. That fixture keeps the user's originAware=true, under which Maven reads checksums-<repoId>.sha256, not this file, so the old attestation was false.

Review findings (/code-review high)

Each finding was confirmed with a failing test on the previous head (26d9d3b) before it was fixed.

1. Fixed: a -Dk=v token inside a longer line no longer counts. Only whole-line arguments do.
2. Fixed: config_enforces now checks all five settings Maven reads the file by, not just the switch. failIfMissing doesn't decide whether a committed line is checked, so it isn't required. The unwind keeps presence semantics on purpose: its warning is about leftover lines hosted mode may have written, and a partial or switched-off set is still worth removing.
3. Fixed: owned-path matching no longer depends on the hash being valid, so stale SRI or truncated lines are dropped on re-pin and unwind, and restore_mvn no longer returns early. Grant hashes are validated when written.
4. Fixed: uppercase hex now gives maven_reads = false and doesn't attest.
5. Fixed: duplicate lines for an owned path collapse to one.
6. Fixed: inserted entries go ahead of the comment block attached to the next entry.
7. Fixed: inserted lines use the file's dominant ending (a tie or no endings gives LF).
8. Fixed: TRUSTED_CHECKSUMS_ON is gone. CONFIG_ARGS and the keys share one literal per prefix.
9. Fixed: discovery applies the same wrapper rule as hosted, and hosted's "enforced" is discovery's.
10. Partly fixed: edit writes into one buffer, with no per-line format!. It still scans once for which owned paths are present before writing. A true single pass can't know whether an owned path appears later without moving that line, and moving it would churn a file the user ordered. The scan is one cheap parse of a tens-of-lines file.

Tests

• maven_checksums_merge_keeps_every_user_line: fails before the first commit, passes after. User lines in single-space, *, tab, comment and stray-text form survive a pin and a re-pin.
• The CRLF re-pin test asserts the file stays CRLF.
• maven_checksums_owned_lines_go_whatever_their_hash: hosted re-pin with stale hashes, and refusal of an invalid grant hash.
• checksums_unwind_drops_owned_lines_whatever_their_hash and checksums_unwind_reads_every_spelling_and_keeps_crlf: the unwind.
• checksums_attest_only_what_maven_enforces: discovery across config, wrapper and spelling cases.
• Reader and rule round trips in formats::maven::trusted_checksums (12 tests).
• every_fail_closed_rewriter_fixture_yields_the_patch_uuid_not_the_token now expects no integrity for mvn-config-merge, for the originAware=true reason above.
• cargo test -p socket-patch-core --lib -- formats::maven vex::discover:: patch::redirect:: vendor::jvm::: 1591 passed, golden included. socket-patch-cli e2e_vex_lockfile + in_process_get_hosted_ecosystems filtered to maven: 20 passed.
• cargo clippy --locked --workspace --all-features -- -D warnings and cargo fmt --all -- --check are clean.

Not done

• Writing to maven.config (merge_mvn_config) is unchanged.
• GNU escaped filenames and BSD-style SHA256 (path) = hash lines are not interpreted. They are kept verbatim.
• A basedir spelled differently from what hosted writes (for example an absolute path to the same directory) counts as not enforced. That errs toward claiming less.

Review findings, round 2 (/code-review high on ec69ff3, cloud routine)

Fixed in a53a056. Each test below failed on ec69ff3.

1. A broken checksum line for the current suffixed version survived: confirmed and fixed. An invalid grant hash writes no line, but a line an earlier release wrote mangled (lowercased base64) for the same path stayed, and Maven fails the build on a mismatch. Those paths are now dropped on a fresh pin and on a re-run (version pin already present). Test: maven_checksums_owned_lines_go_whatever_their_hash (extended).
2. The writer parsed maven.config its own way: confirmed and fixed. merge_mvn_config keyed settings by the raw line[..=eq] prefix. A user's indented, --define k=v, --define=k=v or quoted setting wasn't seen, so hosted appended its own line, and that later line won. The user's value was silently overridden, against the documented contract. The writer now uses maven_config_line_properties, discovery's reader. Test: maven_config_conflict_in_any_spelling_keeps_the_user_value.
3. The rollback's leftover-settings warning was narrowed: confirmed and fixed. config_has_written_settings is presence-based again (maven_config_properties, which also sees a -Dk=v token joined onto a longer line). This matches round 1's "the unwind keeps presence semantics". Test: config_enforces_needs_every_setting_maven_reads_the_file_by (the assertion is flipped).
4. Docs were stale: fixed. The discovery module doc and docs/ecosystems.md now describe the five-setting and wrapper rule and the redirect_maven_trusted_checksums_invalid_hash warning.

Declined:

• Other basedir spellings (${maven.multiModuleProjectDirectory}/..., trailing /). These still count as not enforced. That errs toward claiming less (owner decision 4), as the "Not done" section already says.
• Header comment placement. An inserted line can land above a leading comment block, but that block is attached to the entry after it. The order is deterministic and no line is lost.
• Decoding an SRI-base64 grant hash. The patch server sends hex. Refusing and warning is the fail-closed choice.
• maven.config read twice in discovery, and the trusted_checksums fn/module name clash. Both are minor and left as is.

Tests (cloud run): cargo test -p socket-patch-core --lib -- formats::maven vex::discover:: patch::redirect:: vendor::jvm:: gives 1591 passed. The one failure, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, fails only because the container runs as root, where chmod 0555 doesn't block. CLI e2e_vex_lockfile and in_process_get_hosted_ecosystems filtered to maven pass. clippy and fmt are clean.

Generated by Claude Code