fix: class loading problem with fat jars (#7786)

[Thomas-Bergmann]

Description of Change

Instead of using URL.openStream(), we propose to use the class or classloader getResourceAsStream to load resources from class path.

Related issues

• fixes Resource Loading Issues in fat jars #7786

Have test cases been added to cover the new functionality?

no - if you have any idea how to test a fat jar problem, I would be happy

[aikebah]

@Thomas-Bergmann Your current fix does not carry the core rationale behind the current loading code: to ensure that we only silently load (in addition to user-configured suppressions) project-vetted false positive suppressions that we made part of the codebase (or in rare cases: the similar named file that someone re-packaged together with our classes in one and the same jar-file).

Simply using the classloader (which we did in past) will load a resource from whichever jar-file is the first to contain a dependencycheck-base-suppression.xml resource. At the very least a similar guard as in the original proposed resourceloading in #7544 would be required to validate that we load the resources from the same jar that our own code originates from.

Based on your reported error I believe that original code that was simplified to direct the URL-based loading does not cover the case of your jar, which I wouldn't term as a fat-jar, but as a jar-with-jars. A fat-jar I consider a jar in which the contents of several original jars are merged together, which would perfectly survive the current code as those would use the regular file:-URL scheme. The problematic part in your scenario is the nested: URI scheme that your jar-with-jars capable classloader uses.

[aikebah]

@Thomas-Bergmann looking at Spring's documentation of its nested classloading [1] and the reported error message I expect that it would only be needed to special-case a nested:-prefix detection inside the .jar suffix branch to compose a jar:nested: URL instead of a jar:file: URL from the CodeSource. Would you be willing to test and validate that it indeed makes things work in your setup and adapt your PR accordingly when successful?

As in: the delta would be reduced to only:

diff --git a/core/src/main/java/org/owasp/dependencycheck/analyzer/AbstractSuppressionAnalyzer.java b/core/src/main/java/org/owasp/dependencycheck/analyzer/AbstractSuppressionAnalyzer.java
index e5b928417..54d2b699e 100644
--- a/core/src/main/java/org/owasp/dependencycheck/analyzer/AbstractSuppressionAnalyzer.java
+++ b/core/src/main/java/org/owasp/dependencycheck/analyzer/AbstractSuppressionAnalyzer.java
@@ -199,7 +199,11 @@ public abstract class AbstractSuppressionAnalyzer extends AbstractAnalyzer {
         final URL jarLocation = AbstractSuppressionAnalyzer.class.getProtectionDomain().getCodeSource().getLocation();
         String suppressionFileLocation = jarLocation.getFile();
         if (suppressionFileLocation.endsWith(".jar")) {
-            suppressionFileLocation = "jar:file:" + suppressionFileLocation + "!/" + BASE_SUPPRESSION_FILE;
+            if (suppressionFileLocation.startsWith("nested:")) {
+                suppressionFileLocation = "jar:nested:" + suppressionFileLocation + "!/" + BASE_SUPPRESSION_FILE;
+            } else {
+                suppressionFileLocation = "jar:file:" + suppressionFileLocation + "!/" + BASE_SUPPRESSION_FILE;
+            }
         } else {
             suppressionFileLocation = "file:" + suppressionFileLocation + BASE_SUPPRESSION_FILE;
         }

[1] https://docs.spring.io/spring-boot/specification/executable-jar/jarfile-class.html