chore(ci): gitleaks allowlist for spec/docs markdown false positives - #89

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '\n== .gitleaks.toml ==\n'
cat -n .gitleaks.toml

printf '\n== gitleaks references ==\n'
rg -n "gitleaks|allowlist|path" -S .github . 2>/dev/null | sed -n '1,200p'

Repository: Helpthread/helpthread

Length of output: 23169

🌐 Web query:

gitleaks allowlist path suppress findings matching paths documentation

💡 Result:

To suppress findings by file path in Gitleaks, you can define allowlists in your gitleaks.toml configuration file [1][2]. There are two primary ways to do this depending on whether you want the exclusion to be global or rule-specific [1][3]. Global Allowlists Global allowlists apply to all rules and take precedence over rule-specific allowlists [1]. Use the [allowlist] section to define these [1][3]. [allowlist] description = "global allow list" paths = [ '''path/to/exclude/.*''', '''another/file.json''' ] Rule-Specific Allowlists If you want to exclude a path only for a particular rule, use the [[rules.allowlists]] section nested under the corresponding rule [1][3]. Note that in newer versions (v8.21.0 and later), [rules.allowlist] was replaced by [[rules.allowlists]] to support multiple allowlist entries per rule [1]. [[rules]] id = "my-specific-rule" #... other rule configuration... [[rules.allowlists]] description = "ignore this file for this rule" paths = [ '''path/to/specific/file.js''' ] Important Implementation Details 1. Regular Expressions: The paths field accepts a list of regular expressions [4][5]. Ensure you use triple quotes (''') in your TOML for raw strings to avoid escaping issues with backslashes [1][6]. 2. Conditions: You can combine multiple criteria (like paths, regexes, or commits) within an allowlist using a condition field, which defaults to "OR" [1][5]. Setting condition = "AND" ensures that a finding is only ignored if all defined criteria match [1]. 3. Precedence: Gitleaks applies global allowlists first, followed by rule-specific allowlists [4]. 4. Validation: Always ensure your gitleaks.toml syntax is correct. Using [[rules.allowlists]] without a valid rule id or using unsupported sections can lead to configuration errors [3]. 5. Extending Default Config: When using [extend] useDefault = true, verify that your rule-specific allowlists are correctly targeting the id of the rule you intend to modify [7][3]. For detailed debugging, Gitleaks logs usually indicate whether allowlists were evaluated and applied during a scan [7]. If a path is not being excluded, double-check that the regex pattern matches the file path correctly [8].

Citations:

• 1: https://github.com/gitleaks/gitleaks/blob/83a57244cdd0bfe1634326ab04a29b9b139bf158/README.md
• 2: https://community.atlassian.com/forums/Bitbucket-questions/Can-i-choose-which-files-to-exclude-from-scanning-in-the-git/qaq-p/2913971
• 3: Allowlists not working  gitleaks/gitleaks#1590
• 4: https://deepwiki.com/gitleaks/gitleaks/4.4-allowlists-and-baselines
• 5: https://github.com/gitleaks/gitleaks/blob/4fb43823/config/allowlist.go
• 6: https://github.com/gitleaks/gitleaks/blob/4fb43823/cmd/generate/config/rules/config.tmpl
• 7: Rule-specific allowlist paths not working with extend useDefault = true gitleaks/gitleaks#1844
• 8: Allowlist entry in gitleaks.toml does not skip detection of pattern gitleaks/gitleaks#1878

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Show the exact lines around the allowlist entries
sed -n '1,120p' .gitleaks.toml

# Locate any CI invocation that scans history or uses config flags
rg -n "gitleaks.*detect|gitleaks.*protect|git log|full history|history" -S .github . 2>/dev/null | sed -n '1,200p'

Repository: Helpthread/helpthread

Length of output: 23188