Upgrade to okhttp 5.x

[ovolynets]

Is your feature request related to a problem? Please describe.
The currently used version of okhttp (version 3.14) has been discovered CVE-2021-0341, here it is used:

spring-cloud-kubernetes/spring-cloud-kubernetes-dependencies/pom.xml

Line 42 in 1f17ff5

<okhttp.version>3.14.4</okhttp.version>

Also Sonatype IQ Server reports this transient dependency while scanning the project for CVEs.

Describe the solution you'd like
I suggest to consider an upgrade to a more recent release of okhttp, latest being 5.0.0-alpha.2. Earlier releases such as 4.9.1 currently do not have the fix included yet, unfortunately.
I am not sure without looking at the code that uses okhttp whether this vulnerability can be exploited at all here - I'd ask the develop team to check for this. Thank you.

Additional context
Related issue reported in okhttp

[ovolynets]

Dear erabii, Thanks for your 0.02$ - gives a bit more context. My comments inlined: using alpha does not sound like a very safe thing to do, imo.

I agree, but right now it's the only published version of okhttp. we only use that in spring-cloud-kubernetes-integration-tests and

spring-cloud-kubernetes-examples directly; so from this point of view *only*, this could be a safe-ish change.

that's good to know that there is no interaction with the production code, thank you. the problem is that this is used internally in the kubernetes-client, which

means we will override the version that they use. Currently we are on 11.0.2 version of kubernetes-java-client, but even their latest version is still not on 5.0.x <https://github.com/kubernetes-client/java/blob/master/pom.xml#L54>. This point, invalidates the previous one; making this a non-safe upgrade.

I will address it also there, thank you. There is another open issue to removes this declaration overall <#847>. This would be a more explicit resolution since this is the source of the version that our application picks up. Instead we'd set it elsewhere more explicitly. Best, Oleksandr

…

On Fri, Aug 6, 2021 at 5:10 PM erabii ***@***.***> wrote: Thank you for reporting this. I have a few bullet points here: - using alpha does not sound like a very safe thing to do, imo. - we only use that in spring-cloud-kubernetes-integration-tests and spring-cloud-kubernetes-examples directly; so from this point of view *only*, this could be a safe-ish change. - the problem is that this is used internally in the kubernetes-client, which means we will override the version that they use. Currently we are on 11.0.2 version of kubernetes-java-client, but even their latest version is still not on 5.0.x <https://github.com/kubernetes-client/java/blob/master/pom.xml#L54>. This point, invalidates the previous one; making this a non-safe upgrade. To me, the proper solution is to open this same defect in kubernetes-client <https://github.com/kubernetes-client/java> and see what the leads think about it over there, because from our side directly, it looks like a fairly safe change (since the direct dependency is part of a test project and example, which are not used in production). Just my 0.02$ — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#846 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQP4RXLVLQLV6T4IOB6ZRLT3P3NNANCNFSM5BV3QRVA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[wind57]

Oleksandr,

The solution to this issue really depends on what is going to happen here. Notice that I closed 847, on purpose, and opened 849.

[wind57]

@ryanjbaxter this can be closed now.