-
Notifications
You must be signed in to change notification settings - Fork 597
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
S3 SDK has (too) many dependencies, and some optional peer dependencies which lead to errors / warnings, and some apparently contain vulnerabilities #4797
Comments
Commenting for visibility, seems is new as mentioned, and it present in many libraries [ses,sns, sqs, sts, credentials-provider].
|
Hi @lukaselmer , Thanks for opening this issue. That being said, some of the dependencies you raised here can be removed, and others already have items on our roadmap to either unify, or remove altogether. @baseddevblorp , The SDK team has already released a new version with an updated version of xml parser. The dependency has low risk of being exploited as the SDK uses https and "man in the middle" attacks are unlikely. Just pull the latest version of the SDK to mitigate this. Thanks, |
@RanVaknin what about the warnings that @lukaselmer shows in the original post? I can confirm these warnings as well, even though there is no real issue and everything works as intended in my project.
|
@RanVaknin Having the same issue |
Can conform this (or a similar) webpack error(s) still shows up on
|
Our system reported a vulnerability in
The patched version is |
GitHub has an advisory for it: GHSA-mpg4-rc92-vx8v |
Checkboxes for prior research
Describe the bug
When installing
@aws-sdk/client-s3
, 102 packages are installed. Some of them are not required in many scenarios IMO, e.g.@aws-sdk/md5-js
is available natively using nodejs@aws-sdk/util-utf8-browser
is not used on the server / in a node env@aws-sdk/util-base64
is implemented in the browser@aws-crypto/sha256-browser
is used only in the browser,@aws-crypto/sha256-js
is (probably?) only used on the server@aws-crypto/ie11-detection
is probably (hopefully!?) a thing of the past, and if it is used, it's only used in the browserBy installing so many dependencies, chances are that vulnerabilities are present. At the time of writing,
fast-xml-parser
is vulnerable (ok, this is extermely new, so it may not be a bit unfair to mention this).Furthermore, when building a project with webpack, I get the following warnings / errors:
And yes, I've also noticed
but they don't really solve the core issue IMHO.
I don't know where these modules are used during production, but our tests / use cases apparently work without using these dependencies.
So now I have a lot of packages installed, I don't know which packages are used and which are unused, and our validation team, who validates these packages, have to validate more than 100 packages, and I expect that most of them are not even used. And we install packages in our server / CI, which are not even intended to be used on the server.
SDK version number
@aws-sdk/[email protected], see package-lock.json below for the full list
Which JavaScript Runtime is this issue in?
Node.js
Details of the browser/Node.js/ReactNative version
v18.16.0
Reproduction Steps
Observed Behavior
(Too) Many dependencies are installed, some (most?) of them are unused.
There's a warning when compiling with webpack (missing peer dependencies). I don't know which features use these peer dependencies (missing docs), but apparently we don't use it.
Expected Behavior
Fewer packages are installed, all or almost all are used. I can install only what I need, and I need only a fraction of the features offered by the S3 sdk.
It is clearly documented which features use
@aws-sdk/signature-v4-crt
andaws-crt
. Even better: this feature is extracted in a separate package, so if you don't need it, you don't install it.Possible Solution
Do you think there's a better way to split up the sdk even more? E.g. separate a browser / server package, at least for the most popular packages like (I suppose) S3? Or have a "lite" version of some packages, which include the features used in 99% of the cases? And have a "extended" version of a package, which wrap the APIs that are only used in 1% of the libraries? Or convert more dependencies to peer dependencies, and describe which peer dependencies are used for which platforms / api calls? Or convert more peer dependencies, and create a meta package (e.g. @aws-sdk/client-s3-node) which requires the necessary peer dependencies?
I think it's a difficult problem, but there must be a better way! 🤔
Additional Information/Context
The text was updated successfully, but these errors were encountered: