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

Quarkus opentelemtry extension still depends on an old version of OkHttp #35121

Closed
chberger opened this issue Jul 31, 2023 · 3 comments
Closed
Labels
kind/bug Something isn't working

Comments

@chberger
Copy link
Contributor

chberger commented Jul 31, 2023

Describe the bug

I've found this thread #29520 to get rid of the okhttp dependency. However, according to my dependency resolver, quarkus-opentelemtry:3.2.2.Final has still a runtime dependency to okhttp:3.14.9 and so a transitive dependency to okio:1.17.2. At least for the latter one my vulnerability scanner complains with:

Component OkIO version 1.17.2 with ID maven:com.squareup.okio:okio:1.17.2 violates policy High Severity Security Policy Rule: found vulnerability CVE-2023-3635 with severity HIGH and CVSS score 7.5

Referring to that thread, OkHttp should only be used for testing purposes as a test dependency. Please see #29520 (comment)

Would be nice if somebody could clarify that.

Thanks in advance

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

17

GraalVM version (if different from Java)

No response

Quarkus version or git rev

3.2.2.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Maven 3.9.2

Additional information

No response

@chberger chberger added the kind/bug Something isn't working label Jul 31, 2023
@radcortez
Copy link
Member

In #34647 we dropped the OkHttp implementation and wrote our own using Vert.x. so this shouldn't be a problem for Quarkus 3.3.

@chberger
Copy link
Contributor Author

Would love to see the fix in the Quarkus 3.2.X LTS version as well. Thanks!

@radcortez
Copy link
Member

I think it would be tricky to backport it since it is a significant change, and while we are confident with the new approach, there is always a risk to discover new issues once users move to it. We would certainly prefer to have it around for a few versions to make sure everything is ok.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants