Is there a way to avoid using ancient versions of okhttp and okio when using kubernetes-client?

[xenomachina]

We're using the latest version of kubernetes-client (io.fabric8:kubernetes-client:6.8.0 as I write this), and we've been having a problem for a while now where dependency-check keeps finding CVEs in okio and/or okhttp. Many of these vulnerabilities (eg: CVE-2023-3635 and CVE-2021-0341) have already been fixed in recent versions of those libraries, but it seems that kubernetes-client is depending on really old versions. I tried setting build constraints to avoid the vulnerable versions, but gradle was not able to resolve the dependencies.

I saw some kubernetes-client issues (eg: #2632) that mentioned switching from that old version of okhttp to vert.x or okhttp4, but it's unclear to me of that ever happened, and if so, how can we use kubernetes-client without pulling in these really old okhttp and okio dependencies.

Is there a way for us to avoid using these ancient and vulnerable versions of okhttp and okio when using kubernetes-client?

[rohanKanojia]

Are you asking how to switch underlying HTTP client ? It was done in 6.x (see docs). It can be done by excluding dependency like this:

        <dependency>
            <groupId>io.fabric8</groupId>
            <artifactId>kubernetes-client</artifactId>
            <exclusions>
              <exclusion>
                <groupId>io.fabric8</groupId>
                <artifactId>kubernetes-httpclient-okhttp</artifactId>
              </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>io.fabric8</groupId>
            <artifactId>kubernetes-httpclient-vertx</artifactId>
        </dependency>

[xenomachina]

Thank you!

I didn't see any explanation of how to do it with vert.x in those docs, but using your example I was able to figure out how to get it working for us in Gradle:

implementation("io.fabric8:kubernetes-client:$kubernetes_version") {
    exclude group: 'io.fabric8', module: 'kubernetes-httpclient-okhttp'
}
implementation "io.fabric8:kubernetes-httpclient-vertx:$kubernetes_version"

By the way, is there a reason why exclude is being used for this? In other libraries I've seen where there's a component that the user has to choose an implementation for, instead of making one implementation the default and requiring the clients exclude it if they want a different on, every other library I've used like this omits the implementation dependency so the clients are forced to choose the one that they want.

To be honest, I didn't even know that Gradle even supported excluding transitive dependencies, because in the dozens of other libraries I've used, I've never seen an exclusion before.

[manusa]

Those libraries might not be as old as this one or might have a different legacy than this one.

Traditionally, the Fabric8 Kubernetes Client only supported a single HttpClient implementation (just like the other Java Kubernetes Client alternatives). It wasn't until v6.0 was released a little bit more than a year ago that we provided HttpClient implementation alternatives (at the moment we support OkHttp, vanilla Java JDK HttpClient, Eclipse Jetty, and Eclipse Vert.x). You can even build your own implementation if you want to.

Since there is a huge user-base that depend on the Fabric8 Kubernetes Client (this is the oldest Java Kubernetes Client available), and to ease the migration to v6 from older versions, we opted to keep the OkHttp client implementation as the default. Adding the exclusion is not that hard. And even if you don't add it, if you provide a different HTTP client implementation that one will automatically take precedence.

It would have been nice to switch to vanilla Java Http Client and avoid any dependency to a 3rd party library while still being mostly backwards compatible in terms of dependency configuration. However, the client has some bugs for Java versions earlier than 16, so in the end it wasn't really an option.

I hope this explains why you see a different behavior in our library as compared to others.

[rdesgroppes]

Thanks for all these explanations, it's perfectly clear.
However, it seems to me that the concern about vulnerable dependencies being dragged by default remains unanswered.
In other words, while retaining the current approach you motivate, what's stopping us from moving to OkHttp 4.x?

[rohanKanojia]

I think it was due to okhttp's decision to move to kotlin square/okhttp#4723 .

[manusa]

In other words, while retaining the current approach you motivate, what's stopping us from moving to OkHttp 4.x?

Downstream project concerns (as the one shared by Rohan and others).
The plan is to move to OkHttp 4 now that we have alternate client implementations. However, we still need to figure out how to maybe replace OkHttp as the backend for our MockServer.