Guava version out of date about jackson-datatypes-collections HOT 17 CLOSED

@MichK21 the way we view setting is that it is a minimum version requirement, and that requiring newer minimum will prevent more projects from using module than being more conservative.
Nothing prevents projects from using a newer version, except for strange versioning strategy Guava sometimes follows with quite aggressive deprecation.
Guava version is being upgraded incrementally, however; consider that 2.8 still only required 16.
But there is no single "current version" of Guava -- there is the latest, but various Java projects use various versions (maybe you just meant more recent, but I just wanted to make sure terminology makes sense). And Jackson is not in position to enforce usage as it just tries facilitating the process.

That said it would be great to figure out a way to test cross-version compatibility. If at all possible, module should work with a wide range of Guava "major" versions (their versioning is bit challenging to follow, especially as transitive dependency -- I am not sure if authors fully appreciate challenges of downstream libraries and frameworks that can not dictate versioning, the way Jackson can not for example).

More importantly, could you file specific issue regarding actual back/forwards incompatibility that you mention? This is a valid concern and I think should be addressed. Similarly if you know of other problems it would be great if you could file them separately (or, if similar enough, bundling multiple in one is fine too)?
Sometimes we can use an alternative type or method to support wider range of versions.

from jackson-datatypes-collections.

Unfortunately the current upper limit of version 22 is indeed an issue because if your repo has "only" the current 23.x version available the depenency will not be satisfied. I didn't test it myself but is this limit unintended or does the step from 22 to 23 indeed have breaking changes for this module?

from jackson-datatypes-collections.

This component is essentially community owned, so if anyone has time and interest to investigate compatibility, that would help.

My understanding is that extending range of allowed versions is probably safe, so as long as someone with time could verify locally that build and all tests pass with, new major versions (like 23), I am happy to make change to open branches.

Updating baseline version is bigger question, but now that we plan to do 2.10, I would be open to updating that. Looking at things:

1. Jackson 3.0 seems to move baseline to 20.0 (as of now), could move further
2. Jackson 2.10 could probably upgrade to a later version too, but that's something that should be discussed.
3. We do need to ensure that module at least loads on full Guava version range (so probably min, max version tests) -- not sure if there is an easy way to create something like guava-test sub-project, with no deployable artifacts?

What I would recommend is sending mail to Jackson user (https://groups.google.com/forum/#!forum/jackson-user) or maybe dev (https://groups.google.com/forum/#!forum/jackson-dev) and propose specific upgrade of baseline, regarding Jackson 2.10. Not many users or developers read git repo issue updates I think; but mailing lists have wider reach.

from jackson-datatypes-collections.

Note: I went ahead and sent an email myself.

/cc @stevenschlansker

from jackson-datatypes-collections.

@knorp , how come your repo only has the latest version available? That is likely to cause a lot of problems, Jackson cannot possibly choose a single version that everyone's private repository agrees is the "blessed" version. Sounds like a losing battle to me.

I would agree that Jackson should keep the Guava version reasonably old, so as not to force upgrades on application developers. But of course some baseline updates are advisable over time, as is needed to keep the project fresh and useful :)

Boo on the Guava maintainers for removing methods without having semver. Typical Google OSS, unfortunately :/

from jackson-datatypes-collections.

@stevenschlansker this was a constructed example to illustrate the point that a higher version is not allowed. In my actual case the issue is that I'm working on a fairly large project where other parts (or other developers) would be interested in a more recent guava version but this module is blocking us from upgrading.

@cowtowncoder I'm considering to look into reviewing the version upgrade myself - what's your criteria to accept a pull request here? Green tests or do you expect anything else?

from jackson-datatypes-collections.

Yeah, it wouldn't be a problem at all, except for Guava removing API... Makes more sense that it's a synthetic test.

from jackson-datatypes-collections.

@knorp All green tests, for both minimum and maximum guava versions (may need to locally change deps to do manul run -- ok for me, unless you or someone else figures out a clean way to do integration tests against diff guava versions).

from jackson-datatypes-collections.

To write such a test, you'd likely need a separate module per Guava version (which doesn't need to be installed or deployed by Maven) and dependencyManagement the guava version to the specific one for that test.

from jackson-datatypes-collections.

@stevenschlansker Right, that seems likely. I have built simple tests under

https://github.com/cowtowncoder/jackson-compat-minor

to compare some version compatibility, but it is not easily modifiable across versions of one component, but more across sets.
It could be that some other tools (gradle?) might have more support, or perhaps specific maven plugins. Although the idea of changing versions of dependencies does seem to go against many of Maven's design choices. So maybe it'd be something ... test frameworks tackle? I'm sure there are solutions but I have not worked in cross-version compatibility domain so am not familiar with what is available.

from jackson-datatypes-collections.

There is a security vulnerability in guava versions below 25.1. Users of Jackson-guava could inadvertently be exposed to this if they use the transitive dependency on guava 18.0 without shading.

Since version 21.0, guava has stopped the aggressive deprecation of its APIs, and all non-beta APIs are supported in all future versions. This makes it much less onerous to upgrade Jackson , since going from 18.0 to 21.0 is the same effort as going from 18.0 to 27.1, and all future upgrades should be painless.

Let's please consider this a security issue and upgrade guava to 27.1-jre (latest at time of writing).

from jackson-datatypes-collections.

@mattdarwin At this point everything that I have read suggest that CVE is irrelevant for Jackson, so I hope that next time this gets brought up someone reads through and suggests a feasible mechanism to suggest how it might affect Jackson use case. As I understand it, vulnerability is directly tied to JDK (de)serialization of Guava types, and Jackson does not use JDK serialization for anything.

This is not meant as criticism against your comment, just as general wish... esp. since I have had to deal with similar issue with Jackson databind itself, wherein all Vuln tools seems unable to offer any information regarding actual applicability of optional features.

So upgrade to require later versions has to be evaluated on other merits, weighing for usage of other versions.

As a very concrete example, at my daytime job, company can not actually upgrade beyond Guava 17 at this point.

from jackson-datatypes-collections.

I agree that the CVE is irrelevant for Jackson. But the point is that by including a dependency with a vulnerability in the dependency tree, you are exposing all users of Jackson to the CVE, if they decide to use the transitive guava dependency to do deserialisation.

Another concrete example: where I work (Oracle) we are forbidden from using any library which has a vulnerable dependency. If you're not going to fix, I now need to branch, patch and rebuild myself.

Oracle's policy may be a bit draconian, but I think that the Jackson could be a bit more pro-active when it comes to updates and security.

from jackson-datatypes-collections.

Thankfully you can eat your cake and have it too -- use Maven <dependencyManagement> to version your Guava dependency explicitly, and it will entirely ignore Jackson's preference. This allows you to substitute out the vulnerable dependency without needing to branch or rebuild Jackson.

That allows both you to proceed forward in accordance with your perhaps draconian security policy, and allows Jackson the time to evaluate the upgrade appropriately (often it's a no-brainer but we already got bit by Guava upgrades in particular multiple times, between the policy of deleting features and attaching bizarre-o suffixes to their jars like -android...)

from jackson-datatypes-collections.

In fact, by introducing the upgrade, we are guaranteeing version resolution pain for downstream users. IIRC, since the versions 26.0-jre and 26.0-android do not compare the same, one will be "newer" than the other. Each library much pick which one to depend on (i.e., there is no guava-api that covers both). This means when you run dependency version check plugins, or check for convergence, you will never see the version converge naturally. You are forced to pick with <dependencyManagement> anyway.

(This is all from memory, I apologize if I misstated any details, but there are concrete problems that come by Guava having two different parallel-yet-different releases, introduced after the current version we depend on. I don't personally think this is a reason to block any upgrades, but doing some basic compatibility testing before merging into master might be wise)

from jackson-datatypes-collections.

Users can of course use shading or dependency management to modify the transitive dependency (although that still won't be enough to satisfy Oracle's security policy and approve use of the library).

But I would have thought that Jackson should be supplying the latest secure version of guava by default, and if any users want to explicitly use older, insecure versions of guava, the onus is on them to modify the version.

(Remember that after guava 21.0 all pain relating to upgrades disappears since they stopped removing deprecated methods.)

from jackson-datatypes-collections.

My experience with Guava dependencies is that there is no win-win position anywhere. In fact, to be completely safe, we'd have to use Scalaic "double versioning" which could combine Jackson core version with Guava version.

But I don't have interest in getting into this version matrix challenge... so the best we can do is find a reasonable compromise between bleeding edge and some sort of center of gravity of actual usage.

So instead of arguing that we should go with the latest which will not happen unless someone else wants to step up to own this component -- something I would be HAPPY to let happen :) -- it would make sense to suggest specific version step to get closer to the tip: version to use as baseline for 2.10 and 3.0 is up for grabs.

from jackson-datatypes-collections.