-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Update AzureSearchAdminKey detector #3634
base: main
Are you sure you want to change the base?
Conversation
8d56655
to
1dd64ad
Compare
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.
Single blocking change as it pertains to reformatting RawV2
, otherwise LGTM!
Raw: []byte(resMatch), | ||
RawV2: []byte(resMatch + resServiceMatch), | ||
Raw: []byte(key), | ||
RawV2: []byte(`{"service":"` + service + `","key":"` + key + `"}`), |
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.
Changing the RawV2
value will break some enterprise customers, as we currently have secrets verified using the old key+service
format. This change would orphan previously verified credentials and create duplicates. Is there a reason we can't continue supporting the old format?
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.
Is there a reason we can't continue supporting the old format?
Obviously you get the final say here, but #2128 has been a PITA for me and others using OSS.
TL;DR Most of the existing RawV2
values are suboptional because they smash together text (sometimes without a delimiter) and are devoid of context/keywords. This makes it impossible to programmatically re-construct and re-verify results.
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.
My guess is that when RawV2
was proposed, we didn't account for its visibility in OSS reporting. Wonder if we can find a solution that preserves readability for OSS while avoiding duplicates on the enterprise side?
This likely requires a broader discussion, and I think @zricethezav will have the most input, but I agree that combining multiple credentials makes them difficult to interpret and largely ineffective
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.
My guess is that when RawV2 was proposed, we didn't account for its visibility in OSS reporting. Wonder if we can find a solution that preserves readability for OSS while avoiding duplicates on the enterprise side?
I can't speak to the impact on enterprise. I can revert the change to RawV2
, though I'd prefer to improve it (eventually).
1dd64ad
to
91e6661
Compare
This comment was marked as outdated.
This comment was marked as outdated.
91e6661
to
549eed7
Compare
549eed7
to
c3e1d7a
Compare
c3e1d7a
to
fda5209
Compare
Description:
There are a number of problems with this detector. This Pr attempts to fix some of the glaring issues.
e.g.,
Checklist:
make test-community
)?make lint
this requires golangci-lint)?