Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace --only-verified with --results #3643

Merged
merged 2 commits into from
Dec 5, 2024

Conversation

rgmz
Copy link
Contributor

@rgmz rgmz commented Nov 21, 2024

Description:

This makes sense. It might be best to introduce --results as a hidden command to allow for tweaking/bugfixes before making it generally available and hiding --only-verified.
#2372 (comment)

This PR hides --only-verified and unhides --results. The latter has been in use for the better part of a year and seems to be working well behind the scenes.

Switching the documentation to an explicit --results flag will give people more control over what they see.

Checklist:

  • Tests passing (make test-community)?
  • Lint passing (make lint this requires golangci-lint)?

@rgmz rgmz requested review from a team as code owners November 21, 2024 02:04
@@ -185,7 +185,7 @@ This required Cosign binary to be installed prior to running installation script
Command:

```bash
trufflehog git https://github.com/trufflesecurity/test_keys --only-verified
trufflehog git https://github.com/trufflesecurity/test_keys --results=verified,unknown
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Including both verified and unknown introduces people to the concept beyond simply --only-verified. Surfacing errors is an important part of using TruffleHog effectively.

If they don't like what they see, they can easily remove unknown.

main.go Outdated
results[value] = struct{}{}
case "filtered_unverified":
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

filtered_unverified is a bit wordy. I think filtered is better and fits in with the existing options.

@@ -354,6 +354,7 @@ func (e *Engine) setDefaults(ctx context.Context) {
}
e.notifyVerifiedResults = true
e.notifyUnverifiedResults = true
e.retainFalsePositives = true
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Why didn't TruffleHog find my secret" is a commonly asked question (e.g., #3579). I think it makes sense to log everything by default. Requiring people to know about and opt-in to a special flag can be confusing.

What do you think?

@rgmz rgmz force-pushed the misc/results-flag branch from 4784b7d to 6bb895b Compare November 21, 2024 02:10
@rgmz
Copy link
Contributor Author

rgmz commented Nov 21, 2024

@dustin-decker @rosecodym Thoughts?

Copy link
Collaborator

@rosecodym rosecodym left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking a look at this! I see three changes here:

  • Changing the CLI and docs to use --results instead of --only-verified
    • And including unknown results in the documentation
  • Renaming filtered_unverified to filtered
  • Disabling false positive elimination by default

I support all three of these changes, but I don't think that they should be combined into a single PR like this. I know each individual part is pretty simple, but this stuff has historically been a minefield of unexpected consequences, so I'd like to tread as lightly as possible. Would you mind splitting them up?

@rgmz rgmz force-pushed the misc/results-flag branch 2 times, most recently from 30d2a2a to b4efd10 Compare November 22, 2024 16:19
@rgmz
Copy link
Contributor Author

rgmz commented Nov 22, 2024

Would you mind splitting them up?

Sure. This is now solely the documentation + flag visibility change.

@rgmz rgmz force-pushed the misc/results-flag branch 2 times, most recently from 3193587 to 45fa258 Compare November 27, 2024 00:21
@rgmz rgmz force-pushed the misc/results-flag branch from 45fa258 to 507fddc Compare December 2, 2024 13:28
@rosecodym
Copy link
Collaborator

Sorry for the delay on reviewing this - I came down with pneumonia and this kind of got lost in the shuffle :( It mostly looks good to me, but I'm wondering how unknown results will interact with CI, given that build agents frequently don't have as much network access as local runs. (But maybe that's an argument for including unknown results in CI?) I've asked @zricethezav for his opinion as well.

@rosecodym
Copy link
Collaborator

Zach says:

Include it and if it's too noisy then we just change the documentation

@rosecodym rosecodym merged commit 62bd8df into trufflesecurity:main Dec 5, 2024
13 checks passed
@rgmz rgmz deleted the misc/results-flag branch December 5, 2024 21:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants