Vulnerable Dependencies

The following dependencies / versions have open CVEs against them:

• com.squareup.okhttp3 : logging-interceptor @ 3.8.1

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-20200 (disputed, see lysine-dev/okhttp#4967)

• org.java-websocket : Java-WebSocket @ 1.3.8 (

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11050

• org.msgpack : msgpack-core @ 0.8.16

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-5234 (probably not relevant as against C# implementation)

• io.netty : netty-transport @ 4.1.34.Final

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-16869
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-20444
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-20445
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11612

[om26er]

We dont directly depend on

• com.squareup.okhttp3 : logging-interceptor
• org.java-websocket : Java-WebSocket @ 1.3.8

They might be getting pulled by some other packages. What we could do is to ensure to update all deps to their latest versions.

msgpack and netty, do have newer versions.

Correct. Perhaps this is useful:

[INFO] |  |  +- org.web3j:core:jar:4.2.0:provided
[INFO] |  |  |  +- org.web3j:crypto:jar:4.2.0:provided
[INFO] |  |  |  |  \- org.web3j:rlp:jar:4.2.0:provided
[INFO] |  |  |  +- org.web3j:tuples:jar:4.2.0:provided
[INFO] |  |  |  +- com.github.jnr:jnr-unixsocket:jar:0.21:provided
[INFO] |  |  |  |  +- com.github.jnr:jnr-enxio:jar:0.19:provided
[INFO] |  |  |  |  \- com.github.jnr:jnr-posix:jar:3.0.47:provided
[INFO] |  |  |  +- com.squareup.okhttp3:okhttp:jar:3.8.1:provided
[INFO] |  |  |  |  \- com.squareup.okio:okio:jar:1.13.0:provided
[INFO] |  |  |  +- com.squareup.okhttp3:logging-interceptor:jar:3.8.1:provided
[INFO] |  |  |  +- io.reactivex.rxjava2:rxjava:jar:2.2.2:provided
[INFO] |  |  |  \- org.java-websocket:Java-WebSocket:jar:1.3.8:provided

The bad news on that front is that the latest web3j-core has not updated it's Java-WebSocket dependency.

We're not using any of the "Etherium Client" integration, but that doesn't stop it being flagged by OWASP Dependency Check :-(

[oberstet]

We're not using any of the "Etherium Client" integration, but that doesn't stop it being flagged by OWASP Dependency Check

hhm, argh. I agree, this sucks. we should do sth about it ..

What we could do is to ensure to update all deps to their latest versions.

yes, definitely! for every release of ABJ .. for all dependencies. the default rule should be: "always bump deps to latest upstream version"

We dont directly depend on ..

is there a way to create a dependency tree for java packages like ABJ? is there a way to create a list of deps-of-deps (recursive)? eg we have that for ABPy ...

@oberstet the complete tree of dependencies for any maven project can be generated with the maven dependency plugin's 'dependency:tree' target:

https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html

the output posted above is generated using that method.

how you'd do something similar for ABJ using gradle i don't know, but this seems like a good place to start:

https://docs.gradle.org/current/userguide/userguide_single.html#sec:listing_dependencies

[oberstet]

@om26er so deps are refreshed now via #490 - should we push a v20.6.2 and ship it?

@om26er or 20.7.1 ?

[om26er]

@om26er or 20.7.1 ?

This is now released. Sorry for the delay.