Is your feature request related to a problem? Please describe.
The current azure-identity artifact has some dependencies which will typically only be used at build time. For instance there is a dependency on org.linguafranca.pwdb:KeePassJava2 which is used by the IntelliJCredential implementation. For our production deployment we don't want to pull in this dependency. One reason being is that it transitively depends on org.simpleframework:simple-xml:jar:2.7.1 which has a CVE (see https://nvd.nist.gov/vuln/detail/CVE-2017-1000190). But it also pulls in some other heavy-weight dependencies.
The same may be true for other implementations like VisualStudioCodeCredential.
Describe the solution you'd like
At the very least I would like the documentation to describe which dependencies are only tied to specific non-essential features (like for example IntelliJCredential) and that it is safe to exclude them if this feature is not required. Also it should be documented how to exclude the dependencies.
Describe alternatives you've considered
Alternatives would be to declare the dependencies as optional and document that they must be provided by the client application.
Yet another possibility would be to provide separate Maven artifacts for the various use cases.
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report
Thanks for filing this issue @knutwannheden. We can improve the documentation to make the optional dependencies more clear. @g2vinay can you please follow up?
AFAICT the dependencies are not declared as optional in the Maven module, so perhaps a hint at how to exclude them using the corresponding Maven mechanism would also make sense.
This CVE has been open since 2017 and get's CVSS score 9.1 CRITICAL.
Documentation regarding how to avoid getting this dependency is a good start, but wouldn't it be better to fix the issue?
Since the org.linguafranca.pwdb:KeePassJava2 is used by IntelliJCredential
We managed to get around this by using ManagedIdentityCredentialBuilder instead of DefaultIdentityBuilder on deployement.