fix: class loading problem with fat jars (#7786)#7787
fix: class loading problem with fat jars (#7786)#7787aikebah merged 1 commit intodependency-check:mainfrom
Conversation
|
@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 |
|
@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 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 |
|
Thx. good idea. But your proposal doesn't work directly. So I will investigate it. |
159ef01 to
a9f313a
Compare
|
@Thomas-Bergmann Thanks for the update to the PR and your local tests to get the nested URL properly working |
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
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