[chore] Replace "Trufflehog" with "TruffleHog" (#2584)

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.
 

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.)

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.)

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

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)
 

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