calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
Subject Re: [DISCUSS] Dropping old Guava support
Date Fri, 12 Oct 2018 20:01:19 GMT
The CVE doesn’t seem that serious, since we don’y use either Java or GWT serialization.

I hope and believe that people can use any recent version of Guava with Avatica and Calcite,
including 24.1.1. If not we should fix it urgently.

I’m not sure we need to disable it working with older versions.


> On Oct 12, 2018, at 12:41 PM, Josh Elser <> wrote:
> Hi,
> Guava [11,24.1.1) is marked as being vulnerable via
> Avatica currently depends on Guava 14.x and Calcite on 19.0. I'd like to start a discussion
about how we ensure "safe" hygiene in our dependencies while still ensuring compatibility
> I can see a couple of paths forward which are all related to relocating+bundling Guava
in a non-standard location.
> 1. If we have Guava classes in the "user-facing API" for the projects, we should create
a new module which relocates our version of Guava in a standard place for downstream projects
to know about. This is required for developers to sanely use their IDEs (e.g. if we shade
guava-$x, users cannot depend on guava-$x in their IDE as those classes don't actually exist).
This is the "Maven way" to work around this problem.
> 2. If we only use Guava "internally", we can just shade Guava like normal.
> I think we would require #1, but I haven't done any scan over the codebase recently.
Given #1, we also should think about:
> 1a. Only Avatica has this special artifact for guava (or really, thirdparty dependencies)?
> 1b. Avatica and Calcite each have the special artifact for themselves.
> If we can get away with 1a, great. Otherwise, 1b gives us lots of flexibility. I think
this positions us in a place where we don't force downstream projects to move to a specific
version of Guava (if they have analyzed their usage to know they are not vulnerable to some
security issue).
> - Josh

View raw message