-
Notifications
You must be signed in to change notification settings - Fork 649
Updated EC2 detector to use v2 aws sdk #6878
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?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6878 +/- ##
=======================================
- Coverage 76.1% 76.0% -0.1%
=======================================
Files 219 219
Lines 21299 21304 +5
=======================================
- Hits 16210 16208 -2
- Misses 4529 4534 +5
- Partials 560 562 +2
|
Side note: the other AWS detectors don't use |
@@ -44,28 +46,39 @@ func (fn optionFunc) apply(c *config) { | |||
} | |||
|
|||
// WithClient sets the ec2metadata client in config. | |||
func WithClient(t Client) Option { | |||
func WithClient(t client) Option { |
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.
Hmm, this is going to be problematic.
The function signature here cannot change, that will be a breaking change
- This could be deprecated as well. It needs to be verified that there is never a need for a client to be set here. Likely this is not the case if a user is trying to stub out functionality for testing external to this package.
- The
Client
interface could be extended and a type assertion can be made that will check if the passed client implements the prior functionality. This will mean that backwards compatible support for the existing API needs to be possible (even with the upgrade). - A
ec2/v2
package is created to support the AWS v2 API and this package is deprecated - Maybe some other options ... (?)
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.
Hmm yeah I'm not sure if this just also should've been unexported along with Client or if there's a valid use case for a user to set their own? I see the commit that added it on the off chance you remember the rational behind it #1030 @MrAlias.
If we create a v2 package and deprecate this one, does the v2 package permanently stay as v2
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.
https://go.dev/blog/v2-go-modules
The recommended strategy is to develop v2+ modules in a directory named after the major version suffix.
This allows also nicely deprecating the existing v1 module.
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.
Plan from SIG meeting is to create a v2 of this module.
@@ -4,12 +4,25 @@ go 1.22.0 | |||
|
|||
require ( | |||
github.com/aws/aws-sdk-go v1.55.6 |
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.
How do we plan on mitigating this https://nvd.nist.gov/vuln/detail/CVE-2020-8911 and https://nvd.nist.gov/vuln/detail/CVE-2020-8912 if we are still pulling in this dependency?
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.
Plan from SIG meeting is to create a v2 of this module.
This should solve it
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.
This package will be deprecated as is, a v2 will be created without this dependency
Resolves #6860