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

Updated jackson-databind version to 2.9.9.2 #301

Merged
merged 1 commit into from
Aug 5, 2019
Merged

Updated jackson-databind version to 2.9.9.2 #301

merged 1 commit into from
Aug 5, 2019

Conversation

mibo
Copy link
Contributor

@mibo mibo commented Aug 2, 2019

Updated jackson-databind version to 2.9.9.2 which contains fix for:

Updated jackson-databind version to 2.9.9.2 which contains fix for:
- [CVE-2019-14379](FasterXML/jackson-databind#2387)
- [CVE-2019-14361 / CVE-2019-14439](FasterXML/jackson-databind#2389)
@mibo
Copy link
Contributor Author

mibo commented Aug 2, 2019

In addition a new release after merge would be great 🙂

@mibo
Copy link
Contributor Author

mibo commented Aug 5, 2019

Can I support in any way?

@scottfrederick
Copy link
Contributor

scottfrederick commented Aug 5, 2019

@mibo Is there evidence to suggest that either of these CVEs is likely to impact the Connectors usage of Jackson? The shaded version of Jackson in Connectors is only used to parse VCAP_SERVICES, and it seems unlikely to me that a VCAP_SERVICES payload would contain serialized objects of the types that are excluded in Jackson 2.9.9.2.

I can merge this PR, but I'm hesitant to do a Connectors release for every Jackson version that gets released, as this happens pretty frequently.

Is there something else that is driving the urgency of this?

Note that this project is in maintenance mode. While we will continue to address security-related issues, releases will generally be less frequent than they have been in the past.

@mibo
Copy link
Contributor Author

mibo commented Aug 5, 2019

I can completely understand your point.

Our issue is that we do regular security scans and update vulnerable versions (like jackson-databind).
Because this is re-bundled in the connectors (instead as a transitive dependency) we would like to have new releases.
However after I took a deeper look into those CVEs (based on this Blog article) you are right that the connectors should not be affected.
The only use of the ObjectMapper is in the CloudFoundryConnector and there the “Default Typing” is not enabled (via e.g. objectMapper.enableDefaultTyping()).
Can you confirm this please?

Nevertheless we would be happy about a new release 🙂
And in parallel we check our security processes to be (more) independent from your releases.

@scottfrederick
Copy link
Contributor

Our issue is that we do regular security scans

I was afraid that was the case :-).

The only use of the ObjectMapper is in the CloudFoundryConnector and there the “Default Typing” is not enabled (via e.g. objectMapper.enableDefaultTyping()).
Can you confirm this please?

I concur.

I'll merge the change, but I'd like to wait a while for the release to make sure we don't get another Jackson version bump in the near future (as often happens, it seems).

I recommend looking into the Java CfEnv project mentioned about as a replacement for Connectors. It is a much smaller library, with far fewer dependencies (and no shaded Jackson libs), that delegates most of the work to Spring Boot auto-configuration libs.

@scottfrederick scottfrederick merged commit 94dff58 into spring-cloud:master Aug 5, 2019
@scottfrederick scottfrederick added this to the 2.0.7 milestone Aug 5, 2019
@mibo
Copy link
Contributor Author

mibo commented Aug 5, 2019

Our issue is that we do regular security scans

I was afraid that was the case :-).

Sorry for that 🙃

The only...
Can you confirm this please?

I concur.

Thanks for confirmation.

I'll merge the change, ....

Thanks and I really appreciate this....

...but I'd like to wait a while for the release to make sure we don't get another Jackson version bump in the near future (as often happens, it seems).

...and this is fine for me and as written we also look for better solution in the future.

I recommend looking into the Java CfEnv project...

We also recommended this to our colleagues. However for some it seems to be not that easy.
But still we try to convince them 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants