Skip to content

Conversation

@red-hat-konflux
Copy link

@red-hat-konflux red-hat-konflux bot commented Jun 5, 2025

This PR contains the following updates:

Package Type Update Change
gitleaks/gitleaks repository minor v8.16.4 -> v8.28.0

Note: The pre-commit manager in Renovate is not supported by the pre-commit maintainers or community. Please do not report any problems there, instead create a Discussion in the Renovate repository if you have any questions.


Release Notes

gitleaks/gitleaks (gitleaks/gitleaks)

v8.28.0

Compare Source

Changelog

Optimizations

#​1909 waits to find newlines until a match. This ends up saving a boat load of time since before we were finding newlines for every fragment regardless if a rule matched or not.
#​1908 promoted @​rgmz excellent stopword optimization

Composite Rules (Multi-part or required Rules) #​1905

In v8.28.0 Gitleaks introduced composite rules, which are made up of a single "primary" rule and one or more auxiliary or required rules. To create a composite rule, add a [[rules.required]] table to the primary rule specifying an id and optionally withinLines and/or withinColumns proximity constraints. A fragment is a chunk of content that Gitleaks processes at once (typically a file, part of a file, or git diff), and proximity matching instructs the primary rule to only report a finding if the auxiliary required rules also find matches within the specified area of the fragment.

Proximity matching: Using the withinLines and withinColumns fields instructs the primary rule to only report a finding if the auxiliary required rules also find matches within the specified proximity. You can set:

  • withinLines: N - required findings must be within N lines (vertically)
  • withinColumns: N - required findings must be within N characters (horizontally)
  • Both - creates a rectangular search area (both constraints must be satisfied)
  • Neither - fragment-level matching (required findings can be anywhere in the same fragment)

Here are diagrams illustrating each proximity behavior:

p = primary captured secret
a = auxiliary (required) captured secret
fragment = section of data gitleaks is looking at

    *Fragment-level proximity*               
    Any required finding in the fragment
          ┌────────┐                       
   ┌──────┤fragment├─────┐                 
   │      └──────┬─┤     │ ┌───────┐       
   │             │a│◀────┼─│✓ MATCH│       
   │          ┌─┐└─┘     │ └───────┘       
   │┌─┐       │p│        │                 
   ││a│    ┌─┐└─┘        │ ┌───────┐       
   │└─┘    │a│◀──────────┼─│✓ MATCH│       
   └─▲─────┴─┴───────────┘ └───────┘       
     │    ┌───────┐                        
     └────│✓ MATCH│                        
          └───────┘                        
                                           
                                           
   *Column bounded proximity*
   `withinColumns = 3`                    
          ┌────────┐                       
   ┌────┬─┤fragment├─┬───┐                 
   │      └──────┬─┤     │ ┌───────────┐   
   │    │        │a│◀┼───┼─│+1C ✓ MATCH│   
   │          ┌─┐└─┘     │ └───────────┘   
   │┌─┐ │     │p│    │   │                 
┌──▶│a│  ┌─┐  └─┘        │ ┌───────────┐   
│  │└─┘ ││a│◀────────┼───┼─│-2C ✓ MATCH│   
│  │       ┘             │ └───────────┘   
│  └── -3C ───0C─── +3C ─┘                 
│  ┌─────────┐                             
│  │ -4C ✗ NO│                             
└──│  MATCH  │                             
   └─────────┘                             
                                           
                                           
   *Line bounded proximity*
   `withinLines = 4`                      
         ┌────────┐                        
   ┌─────┤fragment├─────┐                  
  +4L─ ─ ┴────────┘─ ─ ─│                  
   │                    │                  
   │              ┌─┐   │ ┌────────────┐   
   │         ┌─┐  │a│◀──┼─│+1L ✓ MATCH │   
   0L  ┌─┐   │p│  └─┘   │ ├────────────┤   
   │   │a│◀──┴─┴────────┼─│-1L ✓ MATCH │   
   │   └─┘              │ └────────────┘   
   │                    │ ┌─────────┐      
  -4L─ ─ ─ ─ ─ ─ ─ ─┌─┐─│ │-5L ✗ NO │      
   │                │a│◀┼─│  MATCH  │      
   └────────────────┴─┴─┘ └─────────┘      
                                           
                                           
   *Line and column bounded proximity*
   `withinLines = 4`                      
   `withinColumns = 3`                    
         ┌────────┐                        
   ┌─────┤fragment├─────┐                  
  +4L   ┌└────────┴ ┐   │                  
   │            ┌─┐     │ ┌───────────────┐
   │    │       │a│◀┼───┼─│+2L/+1C ✓ MATCH│
   │         ┌─┐└─┘     │ └───────────────┘
   0L   │    │p│    │   │                  
   │         └─┘        │                  
   │    │           │   │ ┌────────────┐   
  -4L    ─ ─ ─ ─ ─ ─┌─┐ │ │-5L/+3C ✗ NO│   
   │                │a│◀┼─│   MATCH    │   
   └───-3C────0L───+3C┴─┘ └────────────┘   

v8.27.2

Compare Source

Changelog

v8.27.1

Compare Source

Changelog

v8.27.0

Compare Source

Changelog

Got another @​bplaxco release. Cheers!

Archive Scanning

Sometimes secrets are packaged within archive files like zip files or tarballs,
making them difficult to discover. Now you can tell gitleaks to automatically
extract and scan the contents of archives. The flag --max-archive-depth
enables this feature for both dir and git scan types. The default value of
"0" means this feature is disabled by default.

Recursive scanning is supported since archives can also contain other archives.
The --max-archive-depth flag sets the recursion limit. Recursion stops when
there are no new archives to extract, so setting a very high max depth just
sets the potential to go that deep. It will only go as deep as it needs to.

The findings for secrets located within an archive will include the path to the
file inside the archive. Inner paths are separated with !.

Example finding (shortened for brevity):

Finding:     DB_PASSWORD=8ae31cacf141669ddfb5da
...
File:        testdata/archives/nested.tar.gz!archives/files.tar!files/.env.prod
Line:        4
Commit:      6e6ee6596d337bb656496425fb98644eb62b4a82
...
Fingerprint: 6e6ee6596d337bb656496425fb98644eb62b4a82:testdata/archives/nested.tar.gz!archives/files.tar!files/.env.prod:generic-api-key:4
Link:        https://github.com/leaktk/gitleaks/blob/6e6ee6596d337bb656496425fb98644eb62b4a82/testdata/archives/nested.tar.gz

This means a secret was detected on line 4 of files/.env.prod. which is in
archives/files.tar which is in testdata/archives/nested.tar.gz.

Currently supported formats:

The compression
and archive
formats supported by mholt's archives package
are supported.

v8.26.0

Compare Source

Changelog

Calling this one @​bplaxco's release as he introduced a really clever method for mixed decoding without sacrificing too much performance. As I stated in his PR, I think he's either a wizard or some time traveling AI. Dude is wicked smaht

Anyways, Gitleaks now supports the following decoders: hex, percent(url enconding), and b64. It's relatively straight forward to add a new decoder so if you're motivated, community contributions are welcomed!

Here's an example:

~/code/gitleaks-org/gitleaks (master) cat decode.txt
text below
aGVsbG8sIHdvcmxkIQ%3D%3D%0A
text above
~/code/gitleaks-org/gitleaks (master) ./gitleaks dir decode.txt --max-decode-depth=2 --log-level=debug

    ○
    │╲
    │ ○
    ○ ░
    ░    gitleaks

4:08PM DBG using stdlib regex engine
4:08PM DBG unable to load gitleaks config from decode.txt/.gitleaks.toml since --source=decode.txt is a file, using default config
4:08PM DBG found .gitleaksignore file: .gitleaksignore
4:08PM DBG segment found: original=[29,38] pos=[29,38]: "%3D%3D%0A" -> "==\n"
4:08PM DBG segment found: original=[11,38] pos=[11,31]: "aGVsbG8sIHdvcmxkIQ==" -> "hello, world!"
4:08PM INF scanned ~50 bytes (50 bytes) in 1.5ms
4:08PM INF no leaks found

v8.25.1

Compare Source

Changelog

Big thanks @​rgmz

v8.25.0

Compare Source

Changelog

v8.24.3

Compare Source

Changelog

v8.24.2

Compare Source

What's Changed

New Contributors

Full Changelog: gitleaks/gitleaks@v8.24.0...v8.24.2

v8.24.1

Compare Source

v8.24.0

Compare Source

Changelog

v8.23.3

Compare Source

Changelog

v8.23.2

Compare Source

Changelog

v8.23.1

Compare Source

Changelog

v8.23.0

Compare Source

Changelog

READ THIS!!! The default gitleaks config now uses [[rules.allowlists]]

### ⚠️ In v8.21.0 `[rules.allowlist]` was replaced with `[[rules.allowlists]]`.
### This change was backwards-compatible: instances of `[rules.allowlist]` still  work.
    #

### You can define multiple allowlists for a rule to reduce false positives.
### A finding will be ignored if _ANY_ `[[rules.allowlists]]` matches.
    [[rules.allowlists]]
    description = "ignore commit A"

### When multiple criteria are defined the default condition is "OR".
### e.g., this can match on |commits| OR |paths| OR |stopwords|.
    condition = "OR"
    commits = [ "commit-A", "commit-B"]
    paths = [
      '''go\.mod''',
      '''go\.sum'''
    ]

### note: stopwords targets the extracted secret, not the entire regex match
### like 'regexes' does. (stopwords introduced in 8.8.0)
    stopwords = [
      '''client''',
      '''endpoint''',
    ]

    [[rules.allowlists]]

### The "AND" condition can be used to make sure all criteria match.
### e.g., this matches if |regexes| AND |paths| are satisfied.
    condition = "AND"

### note: |regexes| defaults to check the _Secret_ in the finding.
### Acceptable values for |regexTarget| are "secret" (default), "match", and "line".
    regexTarget = "match"
    regexes = [ '''(?i)parseur[il]''' ]
    paths = [ '''package-lock\.json''' ]

v8.22.1

Compare Source

Changelog

v8.22.0

Compare Source

Changelog


This bumps the gitleaks binary size from around 8.5MB to 15MB but yields 2-4x speedup. Worth it imo. If you feel strongly against this change feel free to open an issue where we can discuss the tradeoffs in more depth. Credit to @​ahrav

v8.21.4

Compare Source

Changelog

v8.21.3

Compare Source

Changelog

v8.21.2

Compare Source

Changelog

v8.21.1

Compare Source

Changelog

v8.21.0

Compare Source

Changelog

respect @​rgmz @​9999years

⚠️ Note: you may find some findings that were previously ignored if using .gitleaksignore pop up in your scans. This is due to a fix for a long standing bug where gitleaks would incorrectly report merge commit SHAs instead of the actual commit where a secret was introduced. See the following issues for more context:

v8.20.1

Compare Source

Changelog

v8.20.0

Compare Source

Changelog

Huge huge thanks to @​bplaxco for supporting b64 decoding, @​recreator66 for bug fixes, and to @​rgmz for his continued support of the project in the form of PRs and reviews. Thanks you!

New Feature: Decoding

Sometimes secrets are encoded in a way that can make them difficult to find
with just regex. Now you can tell gitleaks to automatically find and decode
encoded text. The flag --max-decode-depth enables this feature (the default
value "0" means the feature is disabled by default).

Recursive decoding is supported since decoded text can also contain encoded
text. The flag --max-decode-depth sets the recursion limit. Recursion stops
when there are no new segments of encoded text to decode, so setting a really
high max depth doesn't mean it will make that many passes. It will only make as
many as it needs to decode the text. Overall, decoding only minimally increases
scan times.

The findings for encoded text differ from normal findings in the following
ways:

  • The location points the bounds of the encoded text
    • If the rule matches outside the encoded text, the bounds are adjusted to
      include that as well
  • The match and secret contain the decoded value
  • Two tags are added decoded:<encoding> and decode-depth:<depth>

Currently supported encodings:

  • base64 (both standard and base64url)

v8.19.3

Compare Source

Changelog

v8.19.2

Compare Source

Changelog

v8.19.1

Compare Source

Changelog

v8.19.0

Compare Source

Changelog

  • 44ad62e Deprecate detect and protect. Add git, dir, stdin (#​1504) HEY THIS IS AN IMPORTANT CHANGE. If it breaks some stuff... sorry, I'll fix it asap, just open an issue and make sure to ping me. The change is meant to be backwards compatible.
  • e93a7c0 Update Harness rules to add _ and - in the account ID part. (#​1503)
  • 4e43d11 chore: fix gl workflow error (#​1487)
  • [bd81872](https://redirect.g

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

To execute skipped test pipelines write comment /ok-to-test.

This PR has been generated by MintMaker (powered by Renovate Bot).

@red-hat-konflux red-hat-konflux bot force-pushed the konflux/mintmaker/konflux-quay-test/gitleaks-gitleaks-8.x branch from 8c2b14a to 9eb82d9 Compare June 12, 2025 09:25
@red-hat-konflux red-hat-konflux bot changed the title chore(deps): update pre-commit hook gitleaks/gitleaks to v8.27.0 chore(deps): update pre-commit hook gitleaks/gitleaks to v8.27.2 Jun 12, 2025
Signed-off-by: red-hat-konflux <126015336+red-hat-konflux[bot]@users.noreply.github.com>
@red-hat-konflux red-hat-konflux bot force-pushed the konflux/mintmaker/konflux-quay-test/gitleaks-gitleaks-8.x branch from 9eb82d9 to 374d3a7 Compare July 24, 2025 05:07
@red-hat-konflux red-hat-konflux bot changed the title chore(deps): update pre-commit hook gitleaks/gitleaks to v8.27.2 chore(deps): update pre-commit hook gitleaks/gitleaks to v8.28.0 Jul 24, 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.

1 participant