You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Owen Nichols <on...@pivotal.io> on 2020/04/06 15:54:53 UTC

Proposal to bring GEODE-7941 to support/1.12

Recently some Geode users have expressed concern that shiro-1.4.1.jar is getting flagged for critical security vulnerability CVE-2020-1957.

Analysis shows that Geode does not use Shiro in a manner that would expose this vulnerability, so maybe there is no need to backport GEODE-7941.

The risk of bringing GEODE-7941 is very low (Shiro 1.5.2 has no API changes or other breaking changes relative to 1.4.1; Shiro rolled its minor version only to make JDK 8 the minimum).  GEODE-7941 has passed all tests on develop.

I am happy to go either way here, so putting it to a vote.  Does 'making Geode 1.12 look better to automated vulnerability scans' qualify as a ‘critical fix’?  A big red flag doesn’t make a good first impression…also it’s not easy for a user to discover for themselves that Geode is not actually vulnerable.  Bringing this fix to support/1.12 might bolster users’ confidence in the Geode community and our new support-branch model.

-Owen

Re: Proposal to bring GEODE-7941 to support/1.12

Posted by Udo Kohlmeyer <ud...@vmware.com.INVALID>.
+1 to backport

On 4/6/20, 9:14 AM, "Anthony Baker" <ab...@pivotal.io> wrote:

    +1 to backport
    
    > On Apr 6, 2020, at 8:54 AM, Owen Nichols <on...@pivotal.io> wrote:
    > 
    > Recently some Geode users have expressed concern that shiro-1.4.1.jar is getting flagged for critical security vulnerability CVE-2020-1957.
    > 
    > Analysis shows that Geode does not use Shiro in a manner that would expose this vulnerability, so maybe there is no need to backport GEODE-7941.
    > 
    > The risk of bringing GEODE-7941 is very low (Shiro 1.5.2 has no API changes or other breaking changes relative to 1.4.1; Shiro rolled its minor version only to make JDK 8 the minimum).  GEODE-7941 has passed all tests on develop.
    > 
    > I am happy to go either way here, so putting it to a vote.  Does 'making Geode 1.12 look better to automated vulnerability scans' qualify as a ‘critical fix’?  A big red flag doesn’t make a good first impression…also it’s not easy for a user to discover for themselves that Geode is not actually vulnerable.  Bringing this fix to support/1.12 might bolster users’ confidence in the Geode community and our new support-branch model.
    > 
    > -Owen

Re: Proposal to bring GEODE-7941 to support/1.12

Posted by Jinmei Liao <ji...@vmware.com.INVALID>.
+1 to backport

On 4/6/20, 9:14 AM, "Anthony Baker" <ab...@pivotal.io> wrote:

    +1 to backport
    
    > On Apr 6, 2020, at 8:54 AM, Owen Nichols <on...@pivotal.io> wrote:
    > 
    > Recently some Geode users have expressed concern that shiro-1.4.1.jar is getting flagged for critical security vulnerability CVE-2020-1957.
    > 
    > Analysis shows that Geode does not use Shiro in a manner that would expose this vulnerability, so maybe there is no need to backport GEODE-7941.
    > 
    > The risk of bringing GEODE-7941 is very low (Shiro 1.5.2 has no API changes or other breaking changes relative to 1.4.1; Shiro rolled its minor version only to make JDK 8 the minimum).  GEODE-7941 has passed all tests on develop.
    > 
    > I am happy to go either way here, so putting it to a vote.  Does 'making Geode 1.12 look better to automated vulnerability scans' qualify as a ‘critical fix’?  A big red flag doesn’t make a good first impression…also it’s not easy for a user to discover for themselves that Geode is not actually vulnerable.  Bringing this fix to support/1.12 might bolster users’ confidence in the Geode community and our new support-branch model.
    > 
    > -Owen

Re: Proposal to bring GEODE-7941 to support/1.12

Posted by Anthony Baker <ab...@pivotal.io>.
+1 to backport

> On Apr 6, 2020, at 8:54 AM, Owen Nichols <on...@pivotal.io> wrote:
> 
> Recently some Geode users have expressed concern that shiro-1.4.1.jar is getting flagged for critical security vulnerability CVE-2020-1957.
> 
> Analysis shows that Geode does not use Shiro in a manner that would expose this vulnerability, so maybe there is no need to backport GEODE-7941.
> 
> The risk of bringing GEODE-7941 is very low (Shiro 1.5.2 has no API changes or other breaking changes relative to 1.4.1; Shiro rolled its minor version only to make JDK 8 the minimum).  GEODE-7941 has passed all tests on develop.
> 
> I am happy to go either way here, so putting it to a vote.  Does 'making Geode 1.12 look better to automated vulnerability scans' qualify as a ‘critical fix’?  A big red flag doesn’t make a good first impression…also it’s not easy for a user to discover for themselves that Geode is not actually vulnerable.  Bringing this fix to support/1.12 might bolster users’ confidence in the Geode community and our new support-branch model.
> 
> -Owen

Re: Proposal to bring GEODE-7941 to support/1.12

Posted by Owen Nichols <on...@pivotal.io>.
There appears to be consensus that this is a critical fix.  I’ve brought the change to support/1.12 and added 1.12.1 to the listed of fixed versions in Jira.

git cherry-pick -x 6fffd5c07a2f67575ccec6d19df48c70a51ab1c3

-Owen

> On Apr 6, 2020, at 10:35 AM, Dan Smith <ds...@pivotal.io> wrote:
> 
> +1
> 
> -Dan
> 
> On Mon, Apr 6, 2020 at 10:30 AM Bruce Schuchardt <bs...@pivotal.io>
> wrote:
> 
>> +1 to backport to support/1.12
>> 
>> On 4/6/20, 8:55 AM, "Owen Nichols" <on...@pivotal.io> wrote:
>> 
>>    Recently some Geode users have expressed concern that shiro-1.4.1.jar
>> is getting flagged for critical security vulnerability CVE-2020-1957.
>> 
>>    Analysis shows that Geode does not use Shiro in a manner that would
>> expose this vulnerability, so maybe there is no need to backport GEODE-7941.
>> 
>>    The risk of bringing GEODE-7941 is very low (Shiro 1.5.2 has no API
>> changes or other breaking changes relative to 1.4.1; Shiro rolled its minor
>> version only to make JDK 8 the minimum).  GEODE-7941 has passed all tests
>> on develop.
>> 
>>    I am happy to go either way here, so putting it to a vote.  Does
>> 'making Geode 1.12 look better to automated vulnerability scans' qualify as
>> a ‘critical fix’?  A big red flag doesn’t make a good first impression…also
>> it’s not easy for a user to discover for themselves that Geode is not
>> actually vulnerable.  Bringing this fix to support/1.12 might bolster
>> users’ confidence in the Geode community and our new support-branch model.
>> 
>>    -Owen
>> 
>> 
>>

Re: Proposal to bring GEODE-7941 to support/1.12

Posted by Dan Smith <ds...@pivotal.io>.
+1

-Dan

On Mon, Apr 6, 2020 at 10:30 AM Bruce Schuchardt <bs...@pivotal.io>
wrote:

> +1 to backport to support/1.12
>
> On 4/6/20, 8:55 AM, "Owen Nichols" <on...@pivotal.io> wrote:
>
>     Recently some Geode users have expressed concern that shiro-1.4.1.jar
> is getting flagged for critical security vulnerability CVE-2020-1957.
>
>     Analysis shows that Geode does not use Shiro in a manner that would
> expose this vulnerability, so maybe there is no need to backport GEODE-7941.
>
>     The risk of bringing GEODE-7941 is very low (Shiro 1.5.2 has no API
> changes or other breaking changes relative to 1.4.1; Shiro rolled its minor
> version only to make JDK 8 the minimum).  GEODE-7941 has passed all tests
> on develop.
>
>     I am happy to go either way here, so putting it to a vote.  Does
> 'making Geode 1.12 look better to automated vulnerability scans' qualify as
> a ‘critical fix’?  A big red flag doesn’t make a good first impression…also
> it’s not easy for a user to discover for themselves that Geode is not
> actually vulnerable.  Bringing this fix to support/1.12 might bolster
> users’ confidence in the Geode community and our new support-branch model.
>
>     -Owen
>
>
>

Re: Proposal to bring GEODE-7941 to support/1.12

Posted by Bruce Schuchardt <bs...@pivotal.io>.
+1 to backport to support/1.12

On 4/6/20, 8:55 AM, "Owen Nichols" <on...@pivotal.io> wrote:

    Recently some Geode users have expressed concern that shiro-1.4.1.jar is getting flagged for critical security vulnerability CVE-2020-1957.
    
    Analysis shows that Geode does not use Shiro in a manner that would expose this vulnerability, so maybe there is no need to backport GEODE-7941.
    
    The risk of bringing GEODE-7941 is very low (Shiro 1.5.2 has no API changes or other breaking changes relative to 1.4.1; Shiro rolled its minor version only to make JDK 8 the minimum).  GEODE-7941 has passed all tests on develop.
    
    I am happy to go either way here, so putting it to a vote.  Does 'making Geode 1.12 look better to automated vulnerability scans' qualify as a ‘critical fix’?  A big red flag doesn’t make a good first impression…also it’s not easy for a user to discover for themselves that Geode is not actually vulnerable.  Bringing this fix to support/1.12 might bolster users’ confidence in the Geode community and our new support-branch model.
    
    -Owen