Closed tomdw closed 1 week ago
cc @rohanKanojia new issue, as you asked
This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!
This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!
Is your enhancement related to a problem? Please describe
We use kubernetes-server-mock 6.9.2 in our project.
There is a CVE problem through the following dependencies:
io.fabric8:kubernetes-server-mock:6.9.2 |--> io.fabric8:mockwebserver:6.9.2 |--> com.squareup.okhttp3:mockwebserver:3.12.12 |--> junit:junit:4.12
The currently used okhttp3 mockwebserver version depends on an old junit version that has vulnerabilities CVE-2020-15250.
Although I use junit5 in my project, I cannot exclude this old junit dependency. For some reason kubernetes-server-mock still requires older org.junit classes even when running junit5 tests.
Describe the solution you'd like
It would be great if the latest version of okhttp is used, i.e. com.squareup.okhttp3:mockwebserver:4.12.0, because it depends on the upgraded 4.13 version of junit which does not have the vulnerability.
In other issues there are discussions that an upgrade from okhttp3 to okhttp4 means an impact because the latter is written in Kotlin. However, that does not give breaking changes to the using libraries. So okhttp4 is a drop-in replacement for okhttp4. It will be a non-breaking upgrade.
In general it would be better if kubernetes-server-mock running in junit5 tests does not need any older junit classes/dependencies at all. But I'm not sure if that would require a fix in kubernetes-server-mock or in the okhttp mockwebserver code.
Describe alternatives you've considered
Excluding the junit dependency. But this fails because somehow older junit classes are needed, even when running in junit5 setup.
Additional context
No response