verify --deep hashes encrypted bytes but compares to the plaintext blob ID, so it fails on healthy snapshots #131

New Issue

2026-09-21T09:44:04+02:00

clawbot commented

2026-09-21 09:44:04 +02:00

Found while adding fault-injection tests for #72.

A blob's hash — its remote filename — is the double SHA256 of the plaintext (internal/blobgen/writer.go, Sum256). Deep verification's final integrity step (internal/vaultik/verify.go, verifyBlobFinalIntegrity) instead hashes the encrypted downloaded bytes with a single SHA256 and compares that to the blob hash. The two can never be equal, so verify --deep fails on every valid blob with blob hash mismatch.

The per-chunk hash checks in the same path are correct; only the final blob-hash comparison is wrong.

Effect: deep verification is unusable — it reports healthy backups as corrupt. The blob-existence stage that runs earlier is unaffected, so a genuinely missing blob is still caught.

Reproduction: internal/vaultik/fault_injection_test.go, TestFaultInjection_DeepVerifyAcceptsHealthySnapshot (skipped, points to this issue).

Model: opus-4-8

Found while adding fault-injection tests for https://git.eeqj.de/sneak/vaultik/issues/72. A blob's hash — its remote filename — is the double SHA256 of the plaintext (`internal/blobgen/writer.go`, `Sum256`). Deep verification's final integrity step (`internal/vaultik/verify.go`, `verifyBlobFinalIntegrity`) instead hashes the encrypted downloaded bytes with a single SHA256 and compares that to the blob hash. The two can never be equal, so `verify --deep` fails on every valid blob with `blob hash mismatch`. The per-chunk hash checks in the same path are correct; only the final blob-hash comparison is wrong. Effect: deep verification is unusable — it reports healthy backups as corrupt. The blob-existence stage that runs earlier is unaffected, so a genuinely missing blob is still caught. Reproduction: `internal/vaultik/fault_injection_test.go`, `TestFaultInjection_DeepVerifyAcceptsHealthySnapshot` (skipped, points to this issue). Model: opus-4-8

clawbot added this to the 1.0.0 milestone 2026-09-21 09:47:34 +02:00

clawbot referenced this issue from a commit

2026-09-21 19:55:34 +02:00

Hash the plaintext, not the encrypted bytes, in verify --deep (closes #131)

clawbot referenced a pull request that will close this issue

2026-09-21 19:55:54 +02:00

Hash the plaintext, not the encrypted bytes, in verify --deep (closes #131) #138

clawbot commented

2026-09-21 19:56:11 +02:00

Fixed in #138 (base next). Deep verification now hashes the decompressed plaintext and compares its double SHA256 to the blob name, instead of single-hashing the encrypted bytes. Added a test that backs up a real snapshot, deep-verifies it (fails before the fix), then flips a byte in one stored blob and confirms deep verification then fails.

Model: opus-4-8

Fixed in https://git.eeqj.de/sneak/vaultik/pulls/138 (base `next`). Deep verification now hashes the decompressed plaintext and compares its double SHA256 to the blob name, instead of single-hashing the encrypted bytes. Added a test that backs up a real snapshot, deep-verifies it (fails before the fix), then flips a byte in one stored blob and confirms deep verification then fails. Model: opus-4-8

clawbot closed this issue

2026-09-21 20:24:37 +02:00

clawbot referenced this issue from a commit

2026-09-21 20:24:38 +02:00

Hash the plaintext, not the encrypted bytes, in verify --deep (closes #131)

clawbot referenced this issue

2026-09-21 20:41:57 +02:00

next: accumulated work for the upcoming release #114

clawbot referenced this issue

2026-09-21 20:46:04 +02:00

Report a prune count that could not be read as unknown, not 0 (closes #96) #139

Sign in to join this conversation.