[DISCUSS] Dropping old Guava support

[Josh Elser <el...@apache.org>]

Hi,

Guava [11,24.1.1) is marked as being vulnerable via 
https://nvd.nist.gov/vuln/detail/CVE-2018-10237

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 downstream.

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

Re: [DISCUSS] Dropping old Guava support

[Josh Elser <el...@apache.org>]

On 10/15/18 12:25 PM, Julian Hyde wrote:
>> What if we switch things around: instead of depending on the older on in the POMs, we switch to the newer one and do release testing around the older ones that folks have an interest in supporting? If a certain module needs a specific version of Guava (e.g. Cassandra tests), then we can mark that version at test-time for that specific module.
> 
> I’m fine with that.
> 
> Guava has always been a special case in my mind - I think of it as part of the environment, like the JVM and Java runtime, and therefore we try to work well with whatever environment the container has chosen. But there’s no reason to endorse old, buggy versions of Guava even if we can support them.
> 
> Also, we should have a plan to de-support old versions. “This the last release of Calcite/Avatica that will support Guava x; next release we will require Guava y or higher."
> 
> Julian
> 

Thanks, Julian. I like your suggestions. Let me put this on queue and 
see what concrete plan I can put together.

Re: [DISCUSS] Dropping old Guava support

[Julian Hyde <jh...@apache.org>]

> What if we switch things around: instead of depending on the older on in the POMs, we switch to the newer one and do release testing around the older ones that folks have an interest in supporting? If a certain module needs a specific version of Guava (e.g. Cassandra tests), then we can mark that version at test-time for that specific module.

I’m fine with that.

Guava has always been a special case in my mind - I think of it as part of the environment, like the JVM and Java runtime, and therefore we try to work well with whatever environment the container has chosen. But there’s no reason to endorse old, buggy versions of Guava even if we can support them.

Also, we should have a plan to de-support old versions. “This the last release of Calcite/Avatica that will support Guava x; next release we will require Guava y or higher."

Julian

Re: [DISCUSS] Dropping old Guava support

[Josh Elser <el...@apache.org>]

Frankly, I think we're being poor citizens by encouraging this kind of 
(poor) dependency hygiene with Guava by defaulting to known vulnerable 
versions in our POMs.

As a library, we should be ensuring that folks can use Avatica/Calcite 
in their applications. This is not only from a compatibility POV (e.g. 
can you use Calcite with your Guava version of choice), but also from a 
confidence in security as not everyone will invest the time to look into 
the details behind a CVE.

Specifically, with our declaration of the old version of Guava in the 
POM, an unsuspecting user may just use that version instead of swapping 
in a newer one. As a library, we don't know how the user may be using 
Calcite -- they may be doing things with Java or GWT serialization.

All that said, I agree that this specific CVE is not a high-risk 
scenario for the project. However, that must be tempered with security 
organizations who treat these issues as black and white. Many security 
organizations in regulated industries don't "care" about the scope of a 
CVE; they simply cannot use a version of software that includes 
"vulnerable" code.

What if we switch things around: instead of depending on the older on in 
the POMs, we switch to the newer one and do release testing around the 
older ones that folks have an interest in supporting? If a certain 
module needs a specific version of Guava (e.g. Cassandra tests), then we 
can mark that version at test-time for that specific module.

- Josh

On 10/12/18 4:01 PM, Julian Hyde wrote:
> 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.
> 
> Julian
> 
> 
>> On Oct 12, 2018, at 12:41 PM, Josh Elser <el...@apache.org> wrote:
>>
>> Hi,
>>
>> Guava [11,24.1.1) is marked as being vulnerable via https://nvd.nist.gov/vuln/detail/CVE-2018-10237
>>
>> 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 downstream.
>>
>> 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
> 

Re: [DISCUSS] Dropping old Guava support

[Julian Hyde <jh...@apache.org>]

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.

Julian


> On Oct 12, 2018, at 12:41 PM, Josh Elser <el...@apache.org> wrote:
> 
> Hi,
> 
> Guava [11,24.1.1) is marked as being vulnerable via https://nvd.nist.gov/vuln/detail/CVE-2018-10237
> 
> 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 downstream.
> 
> 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