Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade kubernetes-server-mock to okhttp4 mockwebserver to avoid vulnerability warning on old junit transitive dependency #5613

Closed
tomdw opened this issue Nov 27, 2023 · 3 comments · Fixed by #6441
Assignees
Milestone

Comments

@tomdw
Copy link

tomdw commented Nov 27, 2023

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

@tomdw
Copy link
Author

tomdw commented Nov 27, 2023

cc @rohanKanojia new issue, as you asked

Copy link

stale bot commented Mar 19, 2024

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!

@stale stale bot added the status/stale label Mar 19, 2024
@stale stale bot closed this as completed Mar 30, 2024
@manusa manusa reopened this Apr 11, 2024
@github-project-automation github-project-automation bot moved this from Done to Planned in Eclipse JKube Apr 11, 2024
@stale stale bot removed the status/stale label Apr 11, 2024
@manusa manusa removed the status in Eclipse JKube Apr 23, 2024
@manusa manusa added this to the 7.0.0 milestone May 2, 2024
Copy link

stale bot commented Aug 3, 2024

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants