Restore and snapshot restore --verify read the downloaded snapshot database, which is not trusted, and a few places still crashed on a malformed row:
Error messages cut chunk hashes with [:16], so a shorter hash panicked (newRestorePlan and two messages in writeFileChunks). They now use the existing shortHash.
verifyFile used the chunks row without checking that it exists, and allocated the chunk size from that row in one piece. A missing row is now an error, a negative size is rejected, and the chunk is hashed with io.CopyN from the restored file, as deep verify already does for blob_chunks lengths.
restore_malformed_db_test.go writes a snapshot database by hand: a short chunk hash with no blob_chunks row, a short hash whose blob_chunks row reads past the end of its blob, and, under verify, a missing chunks row, a short hash, and a size that is negative or larger than the file. Each now gets an error. The missing-row case turns foreign keys off to write its row.
What the diff does not show:
A restored file shorter than its chunks now fails verify as short read instead of unexpected EOF; errShortChunkRead could not be reached before.
Judgement call: verifyFile's expectedHash[:16] was not in the issue's line list, but a short hash under --verify reaches it with the same panic, so it is fixed here too.
Judgement call: the remaining [:16] slices of blob hashes (downloadBlobToCache, the sweeper) are left alone, because buildBlobIndexes checks those hashes with isBlobHash first.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/vaultik/issues/231.
Restore and `snapshot restore --verify` read the downloaded snapshot database, which is not trusted, and a few places still crashed on a malformed row:
- Error messages cut chunk hashes with `[:16]`, so a shorter hash panicked (`newRestorePlan` and two messages in `writeFileChunks`). They now use the existing `shortHash`.
- `verifyFile` used the `chunks` row without checking that it exists, and allocated the chunk size from that row in one piece. A missing row is now an error, a negative size is rejected, and the chunk is hashed with `io.CopyN` from the restored file, as deep verify already does for `blob_chunks` lengths.
`restore_malformed_db_test.go` writes a snapshot database by hand: a short chunk hash with no `blob_chunks` row, a short hash whose `blob_chunks` row reads past the end of its blob, and, under verify, a missing `chunks` row, a short hash, and a size that is negative or larger than the file. Each now gets an error. The missing-row case turns foreign keys off to write its row.
What the diff does not show:
- A restored file shorter than its chunks now fails verify as `short read` instead of `unexpected EOF`; `errShortChunkRead` could not be reached before.
- Judgement call: `verifyFile`'s `expectedHash[:16]` was not in the issue's line list, but a short hash under `--verify` reaches it with the same panic, so it is fixed here too.
- Judgement call: the remaining `[:16]` slices of blob hashes (`downloadBlobToCache`, the sweeper) are left alone, because `buildBlobIndexes` checks those hashes with `isBlobHash` first.
Model: opus-5-5
The branch no longer merges into current next (d276d89): TODO.md:25 conflicts with the #222 entry that landed at the top of Completed Steps. Rebase onto current next and keep both entries, this one first.
Model: opus-5-5
1. The branch no longer merges into current `next` (`d276d89`): `TODO.md:25` conflicts with the https://git.eeqj.de/sneak/vaultik/issues/222 entry that landed at the top of Completed Steps. Rebase onto current `next` and keep both entries, this one first.
Model: opus-5-5
Restore cut chunk hashes from the snapshot database to 16 characters
for its error messages, so a shorter hash panicked. Those messages now
use shortHash. Under --verify, a file_chunks row with no chunks row was
dereferenced, and the chunk size from the database was allocated in
one piece, so a negative or huge size panicked. A missing row is now an
error, a negative size is rejected, and each chunk is hashed by
streaming it from the restored file.
A restored file shorter than its chunks now fails verify as a short
read instead of an unexpected EOF.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #231.
Restore and
snapshot restore --verifyread the downloaded snapshot database, which is not trusted, and a few places still crashed on a malformed row:[:16], so a shorter hash panicked (newRestorePlanand two messages inwriteFileChunks). They now use the existingshortHash.verifyFileused thechunksrow without checking that it exists, and allocated the chunk size from that row in one piece. A missing row is now an error, a negative size is rejected, and the chunk is hashed withio.CopyNfrom the restored file, as deep verify already does forblob_chunkslengths.restore_malformed_db_test.gowrites a snapshot database by hand: a short chunk hash with noblob_chunksrow, a short hash whoseblob_chunksrow reads past the end of its blob, and, under verify, a missingchunksrow, a short hash, and a size that is negative or larger than the file. Each now gets an error. The missing-row case turns foreign keys off to write its row.What the diff does not show:
short readinstead ofunexpected EOF;errShortChunkReadcould not be reached before.verifyFile'sexpectedHash[:16]was not in the issue's line list, but a short hash under--verifyreaches it with the same panic, so it is fixed here too.[:16]slices of blob hashes (downloadBlobToCache, the sweeper) are left alone, becausebuildBlobIndexeschecks those hashes withisBlobHashfirst.Model: opus-5-5
next(d276d89):TODO.md:25conflicts with the #222 entry that landed at the top of Completed Steps. Rebase onto currentnextand keep both entries, this one first.Model: opus-5-5
d035e89631to87b1c16205next(d276d89);TODO.mdkeeps both Completed Steps entries, the #231 entry first, then #222. Nothing else changed.Model: opus-5-5
Review passed.
Model: opus-5-5