feat(java): add support of dependency graph for jar files

[DmitriyLewen]

Description

We already use full path for nested jar files - #3992.
It looks like adding a support dependency tree shouldn't be a problem.

Related Discussions:

• Support transitive dependency information for java container image scans #5469

[knqyf263]

Do you think it is feasible? AFAIK, all dependencies are flattened, and it looks hard to build the dependency tree.

[DmitriyLewen]

I thought of the following logic:
Package from pom.properties (when it matches jar name) or package from MANIFEST is main package, the remaining packages (nested jars, pom.properties with other names) are dependencies of this main package.

[knqyf263]

Interesting. You mean maven doesn't flatten dependencies. Let's see how maven works.

[DmitriyLewen]

I think I understand you
Do you mean that maven just copies class files inside jar file and doesn't use nested jar files?
In this case, we still can't detect these dependencies.

But in some cases, users use nested jars.
for example spring - https://docs.spring.io/spring-boot/docs/current/reference/html/executable-jar.html

In this case, we will find each jar file as a dependency and can create a graph with these dependencies.

But there is problem with shaded jars.
If I remember correctly, main jar contains all required jars and we can't reproduce dependency chains.

[knqyf263]

If my project depends on jackson-databind which depends on jackson-annotations, what does my JAR look like? Does it depend on how to make the JAR file?

<!-- https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind -->
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.15.3</version>
</dependency>

[DmitriyLewen]

Sorry. I missed your message.

I think I understand what you mean.
Maven stores all required libraries in root jar file dir.
We can't build graph in this case.

I used this example to check - https://github.com/OldAl67/Samples.Sample1:

➜   mvn install
...
➜  unzip -d jar ./target/sample1-1.0-SNAPSHOT.jar | grep .jar
...
 extracting: jar/BOOT-INF/lib/spring-boot-starter-web-2.2.2.RELEASE.jar  
 extracting: jar/BOOT-INF/lib/spring-boot-starter-2.2.2.RELEASE.jar  
 extracting: jar/BOOT-INF/lib/spring-boot-2.2.2.RELEASE.jar  
 extracting: jar/BOOT-INF/lib/spring-boot-autoconfigure-2.2.2.RELEASE.jar  
 extracting: jar/BOOT-INF/lib/spring-boot-starter-logging-2.2.2.RELEASE.jar  
 extracting: jar/BOOT-INF/lib/logback-classic-1.2.3.jar  
 extracting: jar/BOOT-INF/lib/logback-core-1.2.3.jar  
 extracting: jar/BOOT-INF/lib/slf4j-api-1.7.29.jar  
 extracting: jar/BOOT-INF/lib/log4j-to-slf4j-2.12.1.jar  
 extracting: jar/BOOT-INF/lib/log4j-api-2.12.1.jar  
 extracting: jar/BOOT-INF/lib/jul-to-slf4j-1.7.29.jar  
 extracting: jar/BOOT-INF/lib/jakarta.annotation-api-1.3.5.jar  
 extracting: jar/BOOT-INF/lib/spring-core-5.2.2.RELEASE.jar  
 extracting: jar/BOOT-INF/lib/spring-jcl-5.2.2.RELEASE.jar  
 extracting: jar/BOOT-INF/lib/snakeyaml-1.25.jar  
 extracting: jar/BOOT-INF/lib/spring-boot-starter-json-2.2.2.RELEASE.jar  
 extracting: jar/BOOT-INF/lib/jackson-databind-2.10.1.jar  
 extracting: jar/BOOT-INF/lib/jackson-annotations-2.10.1.jar  
 extracting: jar/BOOT-INF/lib/jackson-core-2.10.1.jar  
 extracting: jar/BOOT-INF/lib/jackson-datatype-jdk8-2.10.1.jar  
 extracting: jar/BOOT-INF/lib/jackson-datatype-jsr310-2.10.1.jar  
 extracting: jar/BOOT-INF/lib/jackson-module-parameter-names-2.10.1.jar  
 extracting: jar/BOOT-INF/lib/spring-boot-starter-tomcat-2.2.2.RELEASE.jar  
 extracting: jar/BOOT-INF/lib/tomcat-embed-core-9.0.29.jar  
 extracting: jar/BOOT-INF/lib/tomcat-embed-el-9.0.29.jar  
 extracting: jar/BOOT-INF/lib/tomcat-embed-websocket-9.0.29.jar  
 extracting: jar/BOOT-INF/lib/spring-boot-starter-validation-2.2.2.RELEASE.jar  
 extracting: jar/BOOT-INF/lib/jakarta.validation-api-2.0.1.jar  
 extracting: jar/BOOT-INF/lib/hibernate-validator-6.0.18.Final.jar  
 extracting: jar/BOOT-INF/lib/jboss-logging-3.4.1.Final.jar  
 extracting: jar/BOOT-INF/lib/classmate-1.5.1.jar  
 extracting: jar/BOOT-INF/lib/spring-web-5.2.2.RELEASE.jar  
 extracting: jar/BOOT-INF/lib/spring-beans-5.2.2.RELEASE.jar  
 extracting: jar/BOOT-INF/lib/spring-webmvc-5.2.2.RELEASE.jar  
 extracting: jar/BOOT-INF/lib/spring-aop-5.2.2.RELEASE.jar  
 extracting: jar/BOOT-INF/lib/spring-context-5.2.2.RELEASE.jar  
 extracting: jar/BOOT-INF/lib/spring-expression-5.2.2.RELEASE.jar  

I think we can wait for response from users.
If they need this feature - we will check their use cases and try to make it happen.

[knqyf263]

Maven stores all required libraries in root jar file dir.
We can't build graph in this case.

Yes, that is what I was concerned.

[mcandre]

Raw JAR files are named inconsistently, and their contents are inconsistent as well. However, you could reasonably check hashes of the archive against hashes of vulnerable version artifacts.