New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v9.0.0 wishlist #1274
Comments
@zricethezav I'm not sure when the v9 is planned, but I think #1059 should definitely be in there, as it currently makes using .gitleaksignore in a CI environment rather unusable. It seems like a relatively easy fix, but I'm not familiar with Go. |
I've been meaning to respond to this for weeks. To prevent me from putting this off further, I'm going to incrementally update this comment. Right now this isn't in any particular order and is a mix of "I feel really strongly about this" or "this is an idea I had". I will try to refine and categorize it later, as some of these are half-baked.
Non-Breaking ChangesConfig
Tests
|
@rgmz ahh, interesting. So if the secret is
I can see how stopwords is confusing. Stopwords are an efficient way to check if the secret contains any stopwords rather than using regexes in an allowlist. Allowlist.regexes could be applied to the line, match, or secret depending on allowlist.regextarget. The idea was, I think, to provide users the ability to define a regex filter that could be applied anywhere and provide stopwords. Typing this all out reveals to me that it is a bit confusing.... maybe removing stopwords and instead allowing multiple allowlists per rule would be a better design... I'll have to think on this one
I think this could be accomplished pretty easily by adding something like [[rules]]
# ... my rule
[rules.allowlist]
regexTarget = "line"
regexes = [
"blah",
]
paths = ["foo", "bar"]
pathsAndTargetOperator = "or" # or "and" |
Any chance we could source the Current workaround is something like this:
Perhaps the detection logic could fall back to sourcing from the repo directly unless no-git flag is set r, err := git.PlainOpen(".git")
if err != nil {
log.Fatal(err)
}
ref, err := r.Head()
if err != nil {
log.Fatal(err)
}
commit, err := r.CommitObject(ref.Hash())
if err != nil {
log.Fatal(err)
}
tree, err := commit.Tree()
if err != nil {
log.Fatal(err)
}
f, err := tree.File(".gitleaksignore")
if err != nil {
log.Fatal(err)
}
ignore, err := f.Contents()
if err != nil {
log.Fatal(err)
}
fmt.Println(ignore) |
Any way to disable an inherited rule from an extended base config would be very helpful 🙂 It's great to be able to ignore/exclude secret-fingerprints, path-regex, commits and single lines (via comment), but if there is just one rule in the base config which regularly creates false positives you're pretty much forced to stop using the extension mechanism and lose the ability to be kept "up-to-date" automatically 😔 |
Hey all, thanks for all the support and contributions. I'm thinking about doing a breaking change, namely merging
protect
into thedetect
command. I haven't committed totally to this change but it's something that's been in the back of my mind for a while now.If you have other suggestions or features you'd like to see added, throw 'em in this issue.
Thanks!
Zach
The text was updated successfully, but these errors were encountered: