Skip to content

Conversation

rgmz
Copy link
Contributor

@rgmz rgmz commented Mar 1, 2025

Description:

This is a follow-up to #1496. It allows defining multiple global allowlists with independent AND/OR conditions.

Multiple Allowlists

Supports multiple top-level allowlists with AND/OR conditions, similar to multiple rule allowlists added in #1496.

[[allowlists]]
regexes = ["^changeit$"]
[[allowlists]]
condition = "AND"
paths = ["^node_modules/.*"]
stopwords = ["mock"]

Targeted / Reuable Allowlists

Instead of copying & pasting allowlists between multiples rules, the top-level allowlists now have targetRules which will be assigned to the rules at runtime. Allowlists that have targetRules are not added to the global allowlists. (Inspired by Finatext/gls.)

Example: #1777 (comment).

Miscellaneous Changes

  • config.go
    • Include title in the parsed config (inconsequential other than Create command to print config #1654 I think)
    • Unified parsing of allowlists, instead of duplicating the logic.
    • Replaced instances of logging.Fatal() with returning an error to simplify tests
    • Extended config's global allowlists are appended, instead of being merged in
  • detect.go
    • Unified allowlist logic with checkCommitOrPathAllowed and checkFindingAllowed functions, rather than large amounts of duplicated code
  • Tests
    • Added new test cases for the feature
    • Refactored/reorganized existing test cases to clearly differentiate what is being tested, and whether it's a valid/invalid config

Checklist:

  • Does your PR pass tests?
  • Have you written new tests for your changes?
  • Have you lint your code locally prior to submission?

@rgmz rgmz force-pushed the feat/multiple-global-allowlists branch 4 times, most recently from 6a3a2b0 to 2b4f451 Compare March 1, 2025 03:59
@rgmz rgmz force-pushed the feat/multiple-global-allowlists branch 9 times, most recently from c914c1d to 72583b8 Compare March 29, 2025 15:14
@rgmz
Copy link
Contributor Author

rgmz commented Mar 29, 2025

@zricethezav @bplaxco What are your thoughts on this feature (conceptually, ignoring the current ugly code)? It feels quite useful, especially for large configs that have duplicated allowlists that may not be suitable for the global allowlist (e.g., leaktk/patterns#64).

The following are equivalent:

Before

[[rules]]
id = "github-app-token"
regex = '''(?:ghu|ghs)_[0-9a-zA-Z]{36}'''
[[rules.allowlists]]
paths = [
    '''(?:^|/)@octokit/auth-token/README\.md$''',
]

[[rules]]
id = "github-oauth"
regex = '''gho_[0-9a-zA-Z]{36}'''

[[rules]]
id = "github-pat"
regex = '''ghp_[0-9a-zA-Z]{36}'''
[[rules.allowlists]]
paths = [
    '''(?:^|/)@octokit/auth-token/README\.md$''',
]

After

[[rules]]
id = "github-app-token"
regex = '''(?:ghu|ghs)_[0-9a-zA-Z]{36}'''

[[rules]]
id = "github-oauth"
regex = '''gho_[0-9a-zA-Z]{36}'''

[[rules]]
id = "github-pat"
regex = '''ghp_[0-9a-zA-Z]{36}'''

[[allowlists]]
ruleIDs = ["github-app-token", "github-pat"]
paths = [
    '''(?:^|/)@octokit/auth-token/README\.md$''',
]

@bplaxco
Copy link
Contributor

bplaxco commented Mar 29, 2025

@rgmz multiple global allowlists makes sense to me. It mirrors what's on the rules, and I like the idea of having the ability to have a global allowlist with an AND condition apart from the other normal large global allowlist. It'd probably also simplify the code (if this hasn't already been done) for extending existing allowlist config. You'd just append the extended allowlist rather than mutating the existing global one.

@bplaxco
Copy link
Contributor

bplaxco commented Mar 29, 2025

(e.g., leaktk/patterns#64).

Heh aside: in that specific MR I also added support for a # pragma :include: "filename" macro for scripts/compile so I could reference snippets over and over again instead of having to update the same list in a lot of different places. I could have probably added a # pragma :include: "common_password_hash_allowlist" for those.

All that to say, I don't think I'd want gitleaks to allow variables or anything like that for me in the config—I like gitleaks taking a simple static config, but for writing large configs, having a dynamic source is really handy.

@rgmz rgmz force-pushed the feat/multiple-global-allowlists branch 3 times, most recently from ff2ce76 to e7beb14 Compare April 2, 2025 12:57
@rgmz
Copy link
Contributor Author

rgmz commented Apr 2, 2025

It'd probably also simplify the code (if this hasn't already been done) for extending existing allowlist config. You'd just append the extended allowlist rather than mutating the existing global one.

Good point. I've updated the logic to simplify extending:

gitleaks/config/config.go

Lines 441 to 444 in e7beb14

// append allowlists, not attempting to merge
for _, a := range extensionConfig.Allowlists {
c.Allowlists = append(c.Allowlists, a)
}

@rgmz rgmz force-pushed the feat/multiple-global-allowlists branch 2 times, most recently from bbc0c7c to 06b0164 Compare April 2, 2025 13:11
@zricethezav
Copy link
Collaborator

@zricethezav @bplaxco What are your thoughts on this feature (conceptually, ignoring the current ugly code)? It feels quite useful, especially for large configs that have duplicated allowlists that may not be suitable for the global allowlist (e.g., leaktk/patterns#64).

Conceptually, I agree with this proposal. What do you need from me to get this PR from a draft state to a ready state?

@rgmz rgmz force-pushed the feat/multiple-global-allowlists branch 7 times, most recently from f00162e to eb3676b Compare April 5, 2025 17:42
@rgmz rgmz force-pushed the feat/multiple-global-allowlists branch 5 times, most recently from 21f7201 to af8e1b4 Compare April 6, 2025 01:06
@rgmz rgmz marked this pull request as ready for review April 6, 2025 01:24
@rgmz
Copy link
Contributor Author

rgmz commented Apr 6, 2025

What do you need from me to get this PR from a draft state to a ready state?

After a second pass, I'm much happier with how this looks. I think it's ready for review now.

Forgive the large number of files moved. I did shuffle around a bunch of tests in config_test.go and detect_test.go to get a better sense of the cases.

@rgmz rgmz force-pushed the feat/multiple-global-allowlists branch 2 times, most recently from bbc408d to f9b1dea Compare April 12, 2025 16:13
@@ -13,23 +13,9 @@

title = "gitleaks config"

# TODO: change to [[allowlists]]
Copy link
Collaborator

Choose a reason for hiding this comment

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

@rgmz in a fast follow release?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, one or two minor versions later to avoid the compatibility issue from last time. In the future, something like #1754 could catch such issues.

@zricethezav
Copy link
Collaborator

@rgmz could you update the description to be a little more ... descriptive :P, namely targetRules being added and some of the other quality of life improvements you added like moving the tests around and creating some helper functions for config assembly?

@@ -60,18 +62,22 @@ type viperRuleAllowlist struct {
StopWords []string
}

type viperGlobalAllowlist struct {
TargetRules []string
viperRuleAllowlist `mapstructure:",squash"`
Copy link
Collaborator

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I went a bit crazy at first trying to get parseAllowlist to work.

@rgmz rgmz force-pushed the feat/multiple-global-allowlists branch from f9b1dea to e52b2cf Compare April 14, 2025 20:36
@rgmz rgmz force-pushed the feat/multiple-global-allowlists branch from e52b2cf to bb47e30 Compare April 14, 2025 20:54
@rgmz
Copy link
Contributor Author

rgmz commented Apr 14, 2025

@rgmz could you update the description to be a little more ... descriptive :P, namely targetRules being added and some of the other quality of life improvements you added like moving the tests around and creating some helper functions for config assembly?

Great point -- I've updated the PR description. LMK if you feel there's anything I've missed.

@zricethezav zricethezav merged commit 4451b45 into gitleaks:master Apr 29, 2025
2 checks passed
@rgmz rgmz deleted the feat/multiple-global-allowlists branch April 29, 2025 15:09
@rgmz
Copy link
Contributor Author

rgmz commented Apr 29, 2025

FYI @taiki45.

mikhailswift pushed a commit to in-toto/go-witness that referenced this pull request May 13, 2025
Updates gitleaks to v8.26.0.

Gitleaks added the ability to have multiple configured allow lists with
gitleaks/gitleaks#1777 , so this also adjusts
how we add the configured allow list to the detector's config.

Signed-off-by: Mikhail Swift <mikhail@testifysec.com>
colek42 pushed a commit to in-toto/go-witness that referenced this pull request May 16, 2025
Updates gitleaks to v8.26.0.

Gitleaks added the ability to have multiple configured allow lists with
gitleaks/gitleaks#1777 , so this also adjusts
how we add the configured allow list to the detector's config.

Signed-off-by: Mikhail Swift <mikhail@testifysec.com>
alayne222 pushed a commit to alayne222/gitleaks that referenced this pull request May 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants