-
Notifications
You must be signed in to change notification settings - Fork 1.8k
[Feat] Added New AccuWeather Detector Version #4114
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
base: main
Are you sure you want to change the base?
[Feat] Added New AccuWeather Detector Version #4114
Conversation
_ detectors.Detector = (*Scanner)(nil) | ||
|
||
// Make sure that your group is surrounded in boundary characters such as below to reduce false positives. | ||
keyPat = regexp.MustCompile(detectors.PrefixRegex([]string{"accuweather"}) + `\b([a-zA-Z0-9]{32})\b`) |
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.
In my opinion, the pattern difference between V1 and V2 isn’t significant, and both can be validated against the same API. Could we loosen the V1 pattern slightly to accommodate V2 as well?
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.
Hey @kashifkhan0771. I believe the pattern would become \([a-z0-9A-Z\%]{35})|\b[a-zA-Z0-9]{32})\b
, correct?
Other than avoiding the extra computational cost of the regex, I believe having a newer version of the detector may be make it simpler for us to end support for the older version in case we need to.
There's other examples of new versions being added solely to accommodate a pattern difference such as the netlify
v1 and v2 detectors.
What are your thoughts on this?
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.
Giving scanning team approval insofar as this doesn't change secret metadata
@@ -13,7 +13,7 @@ import ( | |||
) | |||
|
|||
type Scanner struct { | |||
client *http.Client | |||
Client *http.Client |
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.
I might have overseen but I could not understand to make it public ?
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.
The v2 integration tests include a test cases that require Client
to be exported, e.g.:
name: "found, real secrets, verification error due to timeout", | |
s: Scanner{Scanner: v1.Scanner{Client: common.SaneHttpClientTimeOut(1 * time.Microsecond)}}, |
matches[k] = struct{}{} | ||
} | ||
allMatches := keyPat.FindAllStringSubmatch(string(data), -1) | ||
return s.VerifyAllMatches(ctx, allMatches, verify) |
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 we call it processMatches
? I believe this function is processing then verifying the findings.
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.
Yes, thanks. That does seem like a more suitable name. Since it needs to be exported, I can rename it to ProcessMatches
.
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.
Updated
Description:
Added a new AccuWeather API detector version to support an updated pattern of keys
Checklist:
make test-community
)?make lint
this requires golangci-lint)?