Okhttp critical vulnerability

[JoseOrtiz]

Okhttp dependency has a high vulnerability fixed on version 4.9.2, as described here

Is there a plan to fix this?

[tstrohmeier]

+1

[devinsba]

Hi folks. Thank you for the report. Unfortunately we cannot update to the 4.x line because it no longer supports Java 7, and requires adding the kotlin runtime which we would not be open to adding to our javaagent. We are looking at mitigating the issue, but the dependency will still exist and still get flagged by peoples security scanners. Long term we would either have to backport the fix or switch to a different client that supports all of our needs

The good news

Fortunately the scope of the security implications of this issue are quite limited for us. The only time there would be secrets in the header values would be when the javaagent is configured in an agentless fashion. So if you are using the javaagent with a standard agent deploy, sending telemetry data to an agent over http, udp, and/or unix domain sockets, then there won't ever be a secret in the headers. Not to mention, it would require that the API key/secret be configured in a malformed way

[devinsba]

We have remediated the issue in #3682. This will be included in the next release

[github-actions]

🤖 This issue has been addressed in the latest release. See full details in the Release Notes.

[deganmee]

This still causes an issue for dev shops that make security a priority; even with patching the exploit, the existence of the library will cause false alerts.

[gsdatta]

+1 to @deganmee, we cannot get past security review in many cases because the JAR still exists on the classpath

[aviorma]

+1
Can we get an ETA for this?

[deganmee]

From a support ticket:

This won’t be fully fixed before our team migrates the Java Tracer to Java 8 minimum, which will take a few weeks at the least.

[bantonsson]

Yes, the official ETA is when we move to Java 8 minimum, which will happen within the next few weeks. I'm sorry that I can't be more precise than that, and it's very unfortunate that it's triggering false alerts in security scanners, but we are working on it.

[deganmee]

Yes, the official ETA is when we move to Java 8 minimum, which will happen within the next few weeks. I'm sorry that I can't be more precise than that, and it's very unfortunate that it's triggering false alerts in security scanners, but we are working on it.

4 weeks later - we appreciate that you are working on this - any updates @bantonsson ?

[bantonsson]

@deganmee Sorry that this is taking so long. Would love for things to move faster. We're tidying up the last few loose ends and are about to communicate with Java 7 customers and give them time to change (if needed) their build/deploy pipelines. The release and switch is expected to happen early November.

[jcoombs-at-cambia]

@bantonsson any updates you can provide?

[bantonsson]

@jcoombs-at-cambia next week. We're really close with the last bits of cleanup.

[tstrohmeier]

@bantonsson When will you release it?

[devinsba]

This was released as part of 1.0.0 so any of the 1.x versions have the fix