Update guava and okhttp versions

usharik commented 2 years ago

Describe the bug There are plenty of well-known vulnerable third parties in Sleath. Why is it so and could that be fixed?

marcingrzejszczak commented 2 years ago

Excuse me but i don't understand what you are talking about. What vulnerable third parties?

usharik commented 2 years ago

At least this one https://mvnrepository.com/artifact/com.google.guava/guava/20.0

marcingrzejszczak commented 2 years ago

We're not using Guava and you have not properly created an issue report. I have no idea which libraries are you referring to, what are the vulnerable versions, where do you think we're setting these versions and how we're using those libraries. You're also not mentioning the version of Sleuth that you think is vulnerable.

usharik commented 2 years ago

@marcingrzejszczak you have it specified in the parent pom of the project

        <guava.version>20.0</guava.version>

marcingrzejszczak commented 2 years ago

Ah indeed we have it for the grpc module (we're actually forcing that version to align with brave). Can you provide the whole list of the dependencies you think we should update?

usharik commented 2 years ago

Here are all I manage to find. Hope that's going to be useful.

spencergibb commented 2 years ago

Is there anything in that list besides guava that is managed directly by sleuth? I think most are managed by spring boot or spring integration that aren't spring cloud projects

usharik commented 2 years ago

I see also version for this one in yor parent pom https://mvnrepository.com/artifact/com.squareup.okhttp3/okhttp/4.9.0

spencergibb commented 2 years ago

Guava may need to wait until brave is updated because it breaks compatibility so often

usharik commented 2 years ago

Honestly, I'm very impressed.

Sleath as a tracing tool is brilliant but also the most loyal software compliance never going to approve a tool with so many vulnerabilities. Do you really never have such problems?

marcingrzejszczak commented 2 years ago

First of all we don't have any reported vulnerabilities and please stop repeating that because you haven't provided any proof for these statements. Also, nobody has reported any problems with the tool.

Second thing is that most of our dependencies are optional.

spencergibb commented 2 years ago

Security vulnerabilities are to be reported here https://spring.io/security-policy as was noted when you created this issue. There are many large projects using sleuth.

jonatan-ivanov commented 2 years ago

Do I understand correctly that the version (20.0) of Guava we use has one low level and one medium level vulnerabilities? The low level does not seem to be fixed (please correct me if I'm wrong), the feature is deprecated. The medium level is only exploitable if you serialize certain classes using Java or GWT serialization. I think there is a very high chance that this is not happening in Sleuth.

The version (4.9.0) of okhttp we use has one high level vulnerability that is only exploitable if you let unsanitized user input into your HTTP headers. Other than this is a bad practice, Sleuth does not do such thing. Also, it seems okhttp is an optional dependency so Sleuth will not bring it to you if you don't explicitly ask for it. When you do, you should be able easily define the patched version: 4.9.2.

Regardless of these, we should upgrade but the fix seems very simple if you are concerned.

spring-cloud / spring-cloud-sleuth

Update guava and okhttp versions #2224