rombert commented on PR #3: URL: https://github.com/apache/sling-org-apache-sling-scripting-javascript/pull/3#issuecomment-2489660324
Thanks for the PR @yuansc . I understand why vulnerability scanners flag this bundle (and many other Sling ones ) as vulnerable but in fact there is no vulnerability. These dependencies are marked as `provided` so they are used when building locally, running tests, and when generating import range for OSGi bundles. At deployment time a different version of those bundles will be used, and that is what the deployer defines. For instance, in the Sling Starter we currently use - org.apache.sling.scripting.javascript 3.1.4 ( https://github.com/apache/sling-org-apache-sling-starter/blob/0fa31f519493dc51071667fffd5b5f011c77704b/src/main/features/scripting.json#L29 ) - commons-io 2.17.0 ( https://github.com/apache/sling-org-apache-sling-starter/blob/0fa31f519493dc51071667fffd5b5f011c77704b/src/main/features/base.json#L146 ) - org.apache.sling.api 2.27.6 ( https://github.com/apache/sling-org-apache-sling-starter/blob/0fa31f519493dc51071667fffd5b5f011c77704b/src/main/features/base.json#L182 ) As you can see, the vulnerable versions are not used at runtime. If we were to merge this PR then we would modify the import ranges of this bundle to no longer work with older verisons of commons-io and org.apache.sling.api. While I personally think it's a bad idea to deploy vulnerable versions, we can't force our users to do that, it must be their action. For this reason we don't usually update dependencies - see https://cwiki.apache.org/confluence/display/SLING/Dependabot for more details, even though it's about automatic updates. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
