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
Add support for #excluding specific rules #142
Conversation
Have you had a chance to take a look at this? |
Sorry I've not been getting many cycles to OSS work. I'd like to get #146 merged before this lands. Awesome work though. |
Sure thing, just give me a heads up when it lands and I can refactor it to
work with the new revision.
…-Jon
On Tue, Dec 12, 2017 at 10:59 PM, Grant Murphy ***@***.***> wrote:
Sorry I've not been getting many cycles to OSS work. I'd like to get #146
<#146> merged before this lands.
Awesome work though.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#142 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AQezTllekoQ7TXCzuyh2cKiZAWB_UCHhks5s_3W9gaJpZM4P3lXI>
.
|
@jonmcclintock not sure if i pinged at you about the rebasing this. if you don't have time I can look at doing it. |
I am also interested in this feature. I think we need only to exclude the rules which produce false positive results. Do you see any use case which requires specific inclusion? Typically all rules are enabled. What do you think about this syntax since there is already
The build constrains in Go could be a source of inspiration: https://golang.org/pkg/go/build/ |
I will be able to get to this next week. Feel free to do if it you've got
the time before then.
…-Jon
On Wed, Feb 7, 2018 at 6:11 PM, Grant Murphy ***@***.***> wrote:
@jonmcclintock <https://github.com/jonmcclintock> not sure if i pinged at
you about the rebasing this. if you don't have time I can look at doing it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#142 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AQezTultr7_cTiQDAGtxjtxGCi10JHuRks5tSlfCgaJpZM4P3lXI>
.
|
analyzer.go
Outdated
matches := re.FindAllStringSubmatch(group.Text(), -1) | ||
|
||
// Find the rule IDs to ignore. | ||
ignores := make([]string, 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can probably use "var ignores []string" instead
Finally got around to rebasing this. Sorry for the delay. |
@cosmincojocar I'm not wed to "exclude" by any means, and "sec" may make more sense. I'll leave it to @gcmurphy to figure out what fits in with his vision of things... |
This is an awesome change and thanks for getting back to it. I'm wondering if it is worth tweaking it a little bit so it is more of an extension to the #nosec directive. Effectively: @jonmcclintock thoughts? Would that be a difficult change to make? If so I'm happy to merge this as is and iterate on it. |
Wouldn't be that hard at all, just a couple of quick changes here: https://github.com/GoASTScanner/gas/pull/142/files#diff-21c43657b6fe53d9635ac2f42896ee61R152 -Jon |
Pushed an updated PR with the changed exclusion syntax. |
Create the ability to exclude specific rules, rather than all of them (with "#nosec"). Works like:
You can specify an arbitrary number of exclusions, and they have the same scoping semantics as "#nosec". You can also add comments to explain your exclusions: