Repository navigation
test(repeat): blob_hash vectors at SHA-1 padding boundaries - #39
Merged
Merged
Conversation
…LF/LF pair against git git hash-object vectors at total lengths (blob header plus content) of 55, 56, 63, 64, 119 and 120 bytes, where hand-written SHA-1 padding typically breaks, and a CRLF/LF pair that must equal git's hash of the LF form. Test-only.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Test-only. Adds
git hash-objectvectors forblob_hashat total lengths (theblob N\0header plus content) of 55, 56, 63, 64, 119 and 120 bytes, keyed by total length with the content length derived from it. Also adds a CRLF/LF pair that must equal git's hash of the LF form (1b39008c...).Why
Hand-written SHA-1 padding is where implementations typically break (55/56, 63/64, 119/120). Not a bug today; this stops a refactor breaking it unnoticed. The existing
sha1_handles_block_boundariesis keyed by content length, so totals 55, 56, 119 and 120 were not covered. Expected values come from runninggit hash-object --stdinon the exact bytes.Meaningful?
Locally broke the padding three ways (0x80 to 0x81, pad target 56 to 55, length word
*8to*7). The new test went red each time (first failure at total 55). All reverted; the diff touches only the test module.Left alone
The hand-written SHA-1 is not replaced with the
sha1crate and no dependency was added; that is the owner's call.Local CI
cargo fmt --all --check: okcargo clippy --workspace --all-targets --exclude Lumen -- -D warnings: okcargo test -p lumen-core -p lumen-cli -p lumen-daemon -p lumen-mcp -p lumen-stats --all-targets --no-fail-fast: all pass except the known environmentalefficiency::the_recorded_ledger_agrees_with_itself(the_recorded_ledger_agrees_with_itself depends on the developer's own ledger #35)Closes #34