From 931a28a537ffcdc4ddb1a5fed715e6b968de3c36 Mon Sep 17 00:00:00 2001 From: Miccah Date: Mon, 18 Mar 2024 11:01:25 -0700 Subject: [PATCH] [chore] Replace "Trufflehog" with "TruffleHog" (#2584) --- README.md | 8 ++++---- hack/docs/Adding_Detectors_Internal.md | 2 +- hack/docs/Adding_Detectors_external.md | 2 +- pkg/detectors/slackwebhook/slackwebhook.go | 2 +- .../trufflehogenterprise/trufflehogenterprise.go | 2 +- pkg/tui/pages/contact_enterprise/contact_enterprise.go | 2 +- 6 files changed, 9 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index 0322999dc..863029d83 100644 --- a/README.md +++ b/README.md @@ -435,11 +435,11 @@ If you'd like to specify specific `base` and `head` refs, you can use the `base` ## Pre-commit Hook -Trufflehog can be used in a pre-commit hook to prevent credentials from leaking before they ever leave your computer. +TruffleHog can be used in a pre-commit hook to prevent credentials from leaking before they ever leave your computer. **Key Usage Note:** -- **For optimal hook efficacy, execute `git add` followed by `git commit` separately.** This ensures Trufflehog analyzes all intended changes. +- **For optimal hook efficacy, execute `git add` followed by `git commit` separately.** This ensures TruffleHog analyzes all intended changes. - **Avoid using `git commit -am`, as it might bypass pre-commit hook execution for unstaged modifications.** An example `.pre-commit-config.yaml` is provided (see [pre-commit.com](https://pre-commit.com/) for installation). @@ -460,13 +460,13 @@ repos: ## Regex Detector (alpha) -Trufflehog supports detection and verification of custom regular expressions. +TruffleHog supports detection and verification of custom regular expressions. For detection, at least one **regular expression** and **keyword** is required. A **keyword** is a fixed literal string identifier that appears in or around the regex to be detected. To allow maximum flexibility for verification, a webhook is used containing the regular expression matches. -Trufflehog will send a JSON POST request containing the regex matches to a +TruffleHog will send a JSON POST request containing the regex matches to a configured webhook endpoint. If the endpoint responds with a `200 OK` response status code, the secret is considered verified. diff --git a/hack/docs/Adding_Detectors_Internal.md b/hack/docs/Adding_Detectors_Internal.md index 866d0d771..c6ec4f993 100644 --- a/hack/docs/Adding_Detectors_Internal.md +++ b/hack/docs/Adding_Detectors_Internal.md @@ -98,7 +98,7 @@ There are two types of reasons that secret verification can fail: * The candidate secret is not actually a valid secret. * Something went wrong in the process unrelated to the candidate secret, such as a transient network error or an unexpected API response. -In Trufflehog parlance, the first type of verification response is called _determinate_ and the second type is called _indeterminate_. Verification code should distinguish between the two by returning an error object in the result struct **only** for indeterminate failures. In general, a verifier should return an error (indicating an indeterminate failure) in all cases that haven't been explicitly identified as determinate failure states. +In TruffleHog parlance, the first type of verification response is called _determinate_ and the second type is called _indeterminate_. Verification code should distinguish between the two by returning an error object in the result struct **only** for indeterminate failures. In general, a verifier should return an error (indicating an indeterminate failure) in all cases that haven't been explicitly identified as determinate failure states. For example, consider a hypothetical authentication endpoint that returns `200 OK` for valid credentials and `403 Forbidden` for invalid credentials. The verifier for this endpoint could make an HTTP request and use the response status code to decide what to return: * A `200` response would indicate that verification succeeded. (Or maybe any `2xx` response.) diff --git a/hack/docs/Adding_Detectors_external.md b/hack/docs/Adding_Detectors_external.md index 5f62f8764..32a578978 100644 --- a/hack/docs/Adding_Detectors_external.md +++ b/hack/docs/Adding_Detectors_external.md @@ -138,7 +138,7 @@ There are two types of reasons that secret verification can fail: * The candidate secret is not actually a valid secret. * Something went wrong in the process unrelated to the candidate secret, such as a transient network error or an unexpected API response. -In Trufflehog parlance, the first type of verification response is called _determinate_ and the second type is called _indeterminate_. Verification code should distinguish between the two by returning an error object in the result struct **only** for indeterminate failures. In general, a verifier should return an error (indicating an indeterminate failure) in all cases that haven't been explicitly identified as determinate failure states. +In TruffleHog parlance, the first type of verification response is called _determinate_ and the second type is called _indeterminate_. Verification code should distinguish between the two by returning an error object in the result struct **only** for indeterminate failures. In general, a verifier should return an error (indicating an indeterminate failure) in all cases that haven't been explicitly identified as determinate failure states. For example, consider a hypothetical authentication endpoint that returns `200 OK` for valid credentials and `403 Forbidden` for invalid credentials. The verifier for this endpoint could make an HTTP request and use the response status code to decide what to return: * A `200` response would indicate that verification succeeded. (Or maybe any `2xx` response.) diff --git a/pkg/detectors/slackwebhook/slackwebhook.go b/pkg/detectors/slackwebhook/slackwebhook.go index ba0892292..d8747a860 100644 --- a/pkg/detectors/slackwebhook/slackwebhook.go +++ b/pkg/detectors/slackwebhook/slackwebhook.go @@ -62,7 +62,7 @@ func (s Scanner) FromData(ctx context.Context, verify bool, data []byte) (result // We don't want to actually send anything to webhooks we find. To verify them without spamming them, we // send an intentionally malformed message and look for a particular expected error message. - payload := strings.NewReader(`intentionally malformed JSON from Trufflehog scan`) + payload := strings.NewReader(`intentionally malformed JSON from TruffleHog scan`) req, err := http.NewRequestWithContext(ctx, "POST", resMatch, payload) if err != nil { continue diff --git a/pkg/detectors/trufflehogenterprise/trufflehogenterprise.go b/pkg/detectors/trufflehogenterprise/trufflehogenterprise.go index 7af19a12d..20955b5a0 100644 --- a/pkg/detectors/trufflehogenterprise/trufflehogenterprise.go +++ b/pkg/detectors/trufflehogenterprise/trufflehogenterprise.go @@ -32,7 +32,7 @@ func (s Scanner) Keywords() []string { return []string{"thog"} } -// FromData will find and optionally verify Trufflehog Enterprise secrets in a given set of bytes. +// FromData will find and optionally verify TruffleHog Enterprise secrets in a given set of bytes. func (s Scanner) FromData(ctx context.Context, verify bool, data []byte) (results []detectors.Result, err error) { dataStr := string(data) diff --git a/pkg/tui/pages/contact_enterprise/contact_enterprise.go b/pkg/tui/pages/contact_enterprise/contact_enterprise.go index 4f345e0c8..83ada4a38 100644 --- a/pkg/tui/pages/contact_enterprise/contact_enterprise.go +++ b/pkg/tui/pages/contact_enterprise/contact_enterprise.go @@ -42,7 +42,7 @@ func (m *ContactEnterprise) Update(msg tea.Msg) (tea.Model, tea.Cmd) { func (m *ContactEnterprise) View() string { s := strings.Builder{} - s.WriteString("Interested in Trufflehog enterprise?\n") + s.WriteString("Interested in TruffleHog enterprise?\n") s.WriteString(linkStyle.Render("🔗 https://trufflesecurity.com/contact")) m.viewed = true