TruffleHog Version
Observed with 3.97.0. The same unchecked slicing is still present in 3.97.1.
Trace Output
https://gist.github.com/posquit0/60c94875200e7b4a3a1b9bd453c01555
The trace and reproducer are synthetic and contain no repository or credential data.
Expected Behavior
pathFromBinaryLine should return ok == false for a malformed or truncated binary-diff line. Invalid Git output should be logged as a parse failure and must not terminate the scan with a panic.
Actual Behavior
The unquoted-path branch removes the expected differ\n suffix with an unchecked slice:
path = string(after[:len(after)-8])
If the content after and b/ is shorter than eight bytes, this causes a negative slice bound and a process-level panic. The quoted-path branch has the same issue with its nine-byte suffix assumption.
Steps to Reproduce
Add the following package-level test in pkg/gitparse/gitparse_test.go and run it:
func TestBinaryPathParseMalformedLine(t *testing.T) {
if path, ok := pathFromBinaryLine([]byte("Binary files /dev/null and b/\n")); ok {
t.Fatalf("expected malformed line to be rejected, got path %q", path)
}
}go test ./pkg/gitparse -run TestBinaryPathParseMalformedLine
The test panics with runtime error: slice bounds out of range [:-7].
A second affected shape is a truncated quoted path such as:
[]byte(`Binary files /dev/null and "b/\n`)
Environment
- OS: Ubuntu 24.04 and macOS
- TruffleHog: 3.97.0; source inspection confirms 3.97.1 is also affected
Additional Context
The parser already returns (string, bool), so malformed input can be handled through the existing parse-failure path. Validating/removing the suffix with bytes.CutSuffix instead of fixed-offset slicing should prevent the panic and also handle a final line without a newline safely.
I plan to submit a small PR with regression tests for unquoted and quoted malformed lines.
References
TruffleHog Version
Observed with
3.97.0. The same unchecked slicing is still present in3.97.1.Trace Output
https://gist.github.com/posquit0/60c94875200e7b4a3a1b9bd453c01555
The trace and reproducer are synthetic and contain no repository or credential data.
Expected Behavior
pathFromBinaryLineshould returnok == falsefor a malformed or truncated binary-diff line. Invalid Git output should be logged as a parse failure and must not terminate the scan with a panic.Actual Behavior
The unquoted-path branch removes the expected
differ\nsuffix with an unchecked slice:If the content after
and b/is shorter than eight bytes, this causes a negative slice bound and a process-level panic. The quoted-path branch has the same issue with its nine-byte suffix assumption.Steps to Reproduce
Add the following package-level test in
pkg/gitparse/gitparse_test.goand run it:go test ./pkg/gitparse -run TestBinaryPathParseMalformedLineThe test panics with
runtime error: slice bounds out of range [:-7].A second affected shape is a truncated quoted path such as:
Environment
Additional Context
The parser already returns
(string, bool), so malformed input can be handled through the existing parse-failure path. Validating/removing the suffix withbytes.CutSuffixinstead of fixed-offset slicing should prevent the panic and also handle a final line without a newline safely.I plan to submit a small PR with regression tests for unquoted and quoted malformed lines.
References