Fix wrong line number in private key detector (#4485) - #4486
Merged
Merged
Conversation
Private key detector findings report wrong line number when private key literal doesn't end with new line character. After private is matched using regexp is goes through Normalize function and normalized result is used in result.Raw and then used in engine.FragmentLineOffset which looks for line of code. Normalization step is crucial as ssh.ParseRawPrivateKey is quite strict about format of accepted key and this step can sieve false posivites as it can verify it private key is legit or just matches permisive regexp. Normalize always adds newline char at end of string (as needed for validation) but such string, with new line at the end is then used for looking for LOC. If source chunk didn't have new line char right after private key engine will report default LOC. This fix changes Result.Raw for private key detector to use raw match from regexp and not normalized string. This way engine can calculate correct LOC for such finding.
kashifkhan0771
requested changes
Oct 8, 2025
| s1 := detectors.Result{ | ||
| DetectorType: detectorspb.DetectorType_PrivateKey, | ||
| Raw: []byte(token), | ||
| Raw: []byte(match), |
Contributor
There was a problem hiding this comment.
We don't recommend updating the Raw field value, as it's used as an identifier and changing it can interfere with existing findings. Your solution is correct, but instead, you can use:
s1.SetPrimarySecretValue(match)This will instruct the engine to use match to determine the line number.
…cret (trufflesecurity#4485) Revert previous changes that changed result.Raw in primary key detector as it can interfere with existing finding. Use SetPrimarySecretValue(match) instead
shahzadhaider1
approved these changes
Oct 13, 2025
kashifkhan0771
approved these changes
Oct 13, 2025
Contributor
|
@trufflesecurity/backend This PR involves a detector change, so I’m not sure why the backend team is the owner. Could someone from the Backend team please review and merge it? |
Contributor
@trufflesecurity/backend owns critical detectors |
rosecodym
approved these changes
Oct 14, 2025
rosecodym
left a comment
rosecodym
left a comment
Contributor
There was a problem hiding this comment.
Thanks for this! I'm mostly deferring to @kashifkhan0771 :)
peterfraedrich
pushed a commit
to peterfraedrich/trufflehog
that referenced
this pull request
Mar 15, 2026
…rufflesecurity#4486) * Fix wrong line number in private key detector (trufflesecurity#4485) Private key detector findings report wrong line number when private key literal doesn't end with new line character. After private is matched using regexp is goes through Normalize function and normalized result is used in result.Raw and then used in engine.FragmentLineOffset which looks for line of code. Normalization step is crucial as ssh.ParseRawPrivateKey is quite strict about format of accepted key and this step can sieve false posivites as it can verify it private key is legit or just matches permisive regexp. Normalize always adds newline char at end of string (as needed for validation) but such string, with new line at the end is then used for looking for LOC. If source chunk didn't have new line char right after private key engine will report default LOC. This fix changes Result.Raw for private key detector to use raw match from regexp and not normalized string. This way engine can calculate correct LOC for such finding. * Fix wrong line number in private key detector - use primary primarySecret (trufflesecurity#4485) Revert previous changes that changed result.Raw in primary key detector as it can interfere with existing finding. Use SetPrimarySecretValue(match) instead --------- Co-authored-by: Kashif Khan <70996046+kashifkhan0771@users.noreply.github.com> Co-authored-by: Shahzad Haider <76992801+shahzadhaider1@users.noreply.github.com>
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
4 participants
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.
Description:
Private key detector findings report wrong line number when private key literal doesn't end with new line character.
After private is matched using regexp is goes through Normalize function and normalized result is used in result.Raw and then used in engine.FragmentLineOffset which looks for line of code.
Normalization step is crucial as ssh.ParseRawPrivateKey is quite strict about format of accepted key and this step can sieve false posivites as it can verify it private key is legit or just matches permisive regexp.
Normalize always adds newline char at end of string (as needed for validation) but such string, with new line at the end is then used for looking for LOC. If source chunk didn't have new line char right after private key engine will report default LOC.
This fix changes Result.Raw for private key detector to use raw match from regexp and not normalized string. This way engine can calculate correct LOC for such finding.
Related issue #4485
Checklist:
make test-community)?make lintthis requires golangci-lint)? - it doesn't even pass for main branch locally