ankitsinghal commented on pull request #68: URL: https://github.com/apache/phoenix-connectors/pull/68#issuecomment-993268146
> Trying to fix indirect dependencies that are not even shipped in the product is a losing game, we should not go down that path. We already have about a dozen of CVEs coming in from the indirect dependencies (Hadop, Hbase), and we as a policy do not do anything about them (apart from upgrading the direct dependency version where we can). Agree we don't do anything today to ban any vulnerable dependency transitively getting included in any of our artifacts (maybe a maven plugin or some CVE scanner could help here), as it is possible that the user changed something unrelated to the vulnerability like just changing the scope of some hive library(as there may not be separate CVE reported for Hive) and without knowing that it is pulling something which makes our shaded artifacts vulnerable. > You could even argue that hiding those dependencies is counter-productive, as even if the problem versions don't show up in a scan, they will still be there in the runtime, and make the production system vulnerable. As long as Phoenix is not affected and Scan shows green, we are good. As we can't do anything about the user runtime as we don't control it, the user has to scan their runtime or deployments from time to time to stay up to date with the CVEs but we can't help to keep their other dependencies always sane. However, I don't feel much strong about this and don't want to put any more wait on fixing the log4j depdency and making a release. Closing this as duplicate. -- 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]
