From b8182c96c285b2f516583677676f3a613e948f1e Mon Sep 17 00:00:00 2001 From: Dai Ha Date: Sat, 12 Sep 2026 15:16:43 +0700 Subject: [PATCH] fleetd #550: pin hash256's algorithm against a literal SHA-256 test vector test_jar_id_defaults_to_live_and_reports_explicit_path's reference hash is computed by calling hash256 itself (needed so it doesn't call the Linux-crashing bare shasum directly). That made subject and reference the same instrument: they agree no matter which algorithm hash256 actually runs, so a mutation swapping both of hash256's arms for the wrong algorithm was invisible to the suite. Adds test_hash256_computes_a_real_sha256, pinned against the published SHA-256 test vector for the 3-byte input "abc" (ba7816bf8f01...), written as a literal constant rather than computed by any hasher at test time. Verified the constant myself both ways (sha256sum and shasum -a 256) before writing it in. --- scripts/test-redeploy-fleetd.sh | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/scripts/test-redeploy-fleetd.sh b/scripts/test-redeploy-fleetd.sh index 6421700..384e9a2 100755 --- a/scripts/test-redeploy-fleetd.sh +++ b/scripts/test-redeploy-fleetd.sh @@ -335,6 +335,26 @@ test_jar_id_defaults_to_live_and_reports_explicit_path() { assert_equals "$staged_hash" "$explicit_result" "jar_id \"\$JAR_STAGED\" must report the hash of the staged jar, not fall back to \$JAR" } +# fleetd #550 — closes a gap the test above leaves open. That test's own reference hash is now ALSO +# computed by calling hash256 (needed for item 2: the old bare macOS-only-hasher call there was the +# Linux crash), so its subject (jar_id, via hash256) and its reference (also hash256) share one +# instrument — they agree no matter which algorithm hash256 actually runs, so a mutation that swaps +# BOTH of hash256's arms for the wrong algorithm is invisible to it. This test's expected value +# comes from neither hasher: it is the published SHA-256 test vector for the 3-byte input "abc" +# (no trailing newline), written here as a literal constant, so it can still tell "hashed +# correctly" from "hashed, just with the wrong algorithm" — which is what this whole ticket is +# about. +test_hash256_computes_a_real_sha256() { + local dir f result + dir="$TMP/hash256-known-vector"; mkdir -p "$dir" + f="$dir/abc.txt" + printf 'abc' > "$f" + result="$(hash256 "$f")" + # SHA-256("abc") = ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad, the standard + # FIPS 180 test vector — first 12 hex chars, matching hash256's own `cut -c1-12`. + assert_equals "ba7816bf8f01" "$result" "hash256 of the literal 3-byte input 'abc' must be the known SHA-256 prefix, not some other algorithm's" +} + # fleetd #517 — jar_id()'s "absent" branch was unpinned by any test: the existing test above (#511) # proves both halves of the present-file contract but never exercises the missing-file path. This # word matters more than a string usually would: "absent" is the #413 signal that a `mvn clean` @@ -1236,6 +1256,7 @@ test_count_daemon_pids test_assert_single_daemon_accepts_one_pid test_assert_single_daemon_rejects_two_pids test_jar_id_defaults_to_live_and_reports_explicit_path +test_hash256_computes_a_real_sha256 test_jar_id_reports_absent_for_missing_file test_jar_id_reports_unhashable_when_no_hasher_on_path test_stage_built_jar_moves_off_live_path