Move to use okhttp4 due to a bug on IPV6 based cluster #2632
Comments
|
Yes, it is. It's a completely different library from 3.x |
|
So what's the solution you envisage? Back porting the fix about IPV6 from okhttp4 to okhttp3 and then updating fabric8? Right now fabric8 is actually bugged with IPV6 clusters due to this problem in okhttp3 :-( |
|
Bumping to 4.x is something that require effort and time. I'm not sure they will backport the fix on 3.x anyway |
|
Well,, that could be a contribution to backport on okhttp3 if they won't do that. Otherwise, you should list this as a well-known bug on fabric8. |
|
Bumping OkHTTP version to 4.x will not only require a lot of work in the client, but some work on the Kubernetes Client Quarkus extension too (I think). I agree that we should eventually upgrade to 4.x, new issues are bound to happen in the future. But I'm not sure if the timing is right at the moment, since we need to deliver 5.0 ASAP. Maybe for the time being contributing a backport of the fix to OkHttp 3.x is more cost-effective WDYT? |
Are we confident the backport would be accepted, though? Or are we talking about maintaining a 3.x fork until the time when we decide to switch to 4? |
|
My suggestion was just (for now) try to see if the back-port is accepted in the OkHttp project, since it's only a few lines (square/okhttp#5889 - haven't checked branch compatibility though). |
|
OkHttp 4.x is binary backwards compatible with OkHttp 3.x. The only breaking experience would be if you have kotlin clients building as it's not source compatible. Full description here https://square.github.io/okhttp/upgrading_to_okhttp_4/ It is not a whole new library, clients can upgrade and downgrade (and do, like in Retrofit) since the public API is maintained. 3.14.x is no longer maintained, so you should upgrade to 4.x unless you wanted legacy support with 3.12.12 (Java 7, Android < 5). See https://square.github.io/okhttp/security/ |
|
okhttp drags in kotlin runtime,right ? that brings its own set of challenges. |
|
I'm not aware of any actual runtime. It uses a kotlin stdlib library, but nothing like a JVM runtime. https://mvnrepository.com/artifact/org.jetbrains.kotlin/kotlin-stdlib-jdk8/1.4.21-2 This is around 20kb. |
|
Any progress with this issue? |
|
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! |
|
Still relevant |
|
Hi, is it already set in stone that fabric8 client replaces okhttp 3 with vert.x client? What are the main advantages from moving to vert.x client? Sometimes I see transitive dependencies of okhttp as a motivation. I´m wondering where that comes from because when comparing the dependencies of Also from a size point of view, its I agree that the project should replace okhttp 3 rather sooner than later. And if you prefer vert.x over okhttp, that's perfectly fine. Just interested in the reasons for it :) |
|
One issue is having a dependency that requires a full kotlin build to rebuild from source. (Afaik) Other is that by using vert.x we can share and optimize http stacks with frameworks like vert.x itself and quarkus. Optimally the http client layer would be pluggable but not sure how feasible that is. |
|
What do you mean about full Kotlin build? And from source? OkHttp itself is near 100% Kotlin. But it's just a java jar when you use it as a dependency. |
|
@ppatierno: Hello, I'm looking into this issue. I reproduced your issue by using KubernetesClient with a kind cluster with ipv6 configuration specified in kind docs[0]. Are you able to resolve your issue by excluding okhttp3 dependencies introduced by kubernetes-client jar and adding direct okhttp 4 dependencies? I tested this on a simple reproducer project[1] on a ipv6 kind cluster and it seems to be working fine for me. <properties>
<fabric8.version>5.5.0</fabric8.version>
<okhttp.version>4.9.0</okhttp.version>
</properties>
<dependencies>
<dependency>
<groupId>io.fabric8</groupId>
<artifactId>kubernetes-client</artifactId>
<version>${fabric8.version}</version>
<exclusions>
<exclusion>
<groupId>com.squareup.okhttp3</groupId>
<artifactId>okhttp</artifactId>
</exclusion>
<exclusion>
<groupId>com.squareup.okhttp3</groupId>
<artifactId>logging-interceptor</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.squareup.okhttp3</groupId>
<artifactId>okhttp</artifactId>
<version>${okhttp.version}</version>
</dependency>
<dependency>
<groupId>com.squareup.okhttp3</groupId>
<artifactId>logging-interceptor</artifactId>
<version>${okhttp.version}</version>
</dependency>
</dependencies>I also checked to upgrade Okhttp in KubernetesClient to v4.9.0: I was able to get that reproducer project working on Kind ipv6 cluster with I tested this with Quarkus KubernetesClient Extension as well, I'm able to get it working on a Kubernetes ipv6 cluster with the above exclusions. You can see the full project here. [0] https://kind.sigs.k8s.io/docs/user/configuration/#ip-family |
|
Hello community! I would also be interested in either upgrading okhttp or the migration to Vert.x - whatever is decided upon. Reason: CVE-2021-0341 reported by NexusIQ in okhttp in versions prior to 4.9.1, see square/okhttp#6724 for details. The upgrade of okhttp to Who can make the decision or either ways to proceed with eliminating the CVE rather than implementing a workaround (e.g. as was suggested earlier for a different problem #2632 (comment))? Thanks UPD: |
|
@ovolynets the CVE isn't exploitable unless you take the HostnameVerifier from OkHttp and use it for other purposes. Unless you are doing something like that which would be really strange, it isn't exploitable at all. |
|
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! |
|
Are there still planes to upgrade to okhttp4? the 3.x version depends on an older junit dependency from kubernetes-server-mock through mockwebserver of okhttp3. And this gives CVE vulnerability warning in the IDE. |
|
@manusa Kubernetes client does not rely on okhttp anymore - it's uses vertx. Mockserver using okhttp is unfortunate. Not sure what the cure is here. For now you can manually override the version. |
|
Hi @maxandersen
I'm not sure if your intention was to tag me here or you wanted to reply to Fabric8 Kubernetes Client relies on OkHttp for its @tomdw, as Max said, you should be able to override the OkHttp version for MockWebServer by forcing the dependency to a newer OkHttp version like documented here.
Our |
|
As part of the #5778 initiative, we should no longer support OkHttp v3. This issue is now the placeholder for all tasks related to the bump of OkHttp to the latest v4. Changes should be smooth since OkHttp 4 should be binary and source compatible with OkHttp 3, for any incompatibilities please check https://square.github.io/okhttp/changelogs/upgrading_to_okhttp_4/ |
The current version of fabric8 Kubernetes client is using okhttp3 library which is affected by bug on hostname verification when connecting to the Kubernetes server API in IPV6 based cluster.
The same bug affects even the kubernetes-client Java library: kubernetes-client/java#1289
This issue was fixed in okhttp4 as you can see from this already merged PR:
square/okhttp#5889
We are facing this while using fabric8 in the Strimzi operator. There is a workaround as described here strimzi/strimzi-kafka-operator#4002 but it's just a workaround.
Is there any plan to update the fabric8 client to the okhttp4 library version?
The text was updated successfully, but these errors were encountered: