Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork1.4k
fix: class loading problem with fat jars (#7786)#7787
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
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 |
aikebah commentedJul 12, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
@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.javaindex 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 |
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