Mailing-List: contact dev-help@apex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apex.apache.org
Subject: Re: checking dependencies for known vulnerabilities
To: dev@apex.apache.org
References: <f6a88b3e-3fb0-6e63-1514-83d0ff50c1b1@gmail.com>
 <CA+5xAo2MTJR9SLC99it-w47vAbH9x7sEFJEQVX_y3_XfObANfQ@mail.gmail.com>
 <CAA7LveHEinPXrChy__tWPmtbc+82s+9PGOZMynX4cLT5cEO_Gw@mail.gmail.com>
 <39e50723-9e96-a1dd-590b-c74394535f88@apache.org>
 <CAA7LveEUWRWTRVwNv3C2Y_VuU+EeuinMy3dYTpqo02PekmGjVQ@mail.gmail.com>
 <CA+5xAo1moEr=O8FyBzCTkG96WYp3NOsaZRW_kFjuLjGZXCYj_Q@mail.gmail.com>
 <61435004-3760-6b41-e859-e7dc38a9eae1@apache.org>
 <CAA7LveF+J69aJCNJBn4Fa7d+S1zTZk871G5f9QBUumGDeEXxBw@mail.gmail.com>
 <CALPtS-KFDW8BQS6GqGV8fDkFivFyS_CTv1OYq9znSPEoRWEUpA@mail.gmail.com>
 <69269b43-aa7a-f46a-acec-a884f66e1ca8@apache.org>
 <CAKt=akHVz=_VNRTeS4_ux2jHnuPf0pFjRsL75Ab1J0WwENK0HA@mail.gmail.com>
 <c542d182-62ba-5371-d9e3-308507762caf@apache.org>
 <CALPtS-JPcDREXO7K5ucDmX5K2DH1RhTvdL51GYxcPMFWYFvVUA@mail.gmail.com>
From: Vlad Rozov <vrozov@apache.org>
Organization: Apache Software Foundation
Message-ID: <1990549a-78c3-8e44-d9f3-a6522d02a998@apache.org>
Date: Mon, 11 Sep 2017 22:59:17 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
 Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CALPtS-JPcDREXO7K5ucDmX5K2DH1RhTvdL51GYxcPMFWYFvVUA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
archived-at: Tue, 12 Sep 2017 05:59:27 -0000

So, you are saying that those members are eager to see new features, new 
functionalities and new code added to the project? Why they are not 
eager to see a unit test being fixed or a dependency with a severe 
security risk being removed? It is not that their original PR would be 
closed as a result of a unit test fix. What prevents those community 
members to put time and effort to fix CI build (unit test, dependency) 
that will directly benefit the community but may not immediately benefit 
a vendor and its (paying) customers?

Thank you,

Vlad

On 9/11/17 22:08, Sanjay Pujare wrote:
> Comments inline:
>
>
>> On 9/10/17 23:40, Priyanka Gugale wrote:
>>
>>> It's good idea to check for vulnerabilities, but as Pramod said all
>>> softwares / libraries are going to have some or other vulnerability at any
>>> time. I will go with approach of "let's discuss this addition" and we
>>> should not affect PRs which are not adding any new dependencies (due to
>>> old
>>> vulnerabilities).
>>>
>> While all software/libraries are subject to insecure code and
>> vulnerabilities, all software vendors whether open or close source
>> hopefully try to make code more secure rather than insecure. If there is an
>> existing or newly introduced dependency with a critical security issue, I
>> don't see why Apex community wants to accept the high probability of being
>> exposed to a security exploit. The only reasonable explanation for me is
>> that the community members do not care about overall project quality and
>> care only for tasks/PRs assigned to them by somebody else. I'll be glad to
>> hear a different explanation for the proposal not to penalize PRs that do
>> not introduce new dependencies and are affected by a newly found
>> vulnerability in an existing dependency. Will not we all be penalized later
>> if we don't fix it?
>>
>
> I take exception to the insinuation that (some) community members "care
> only for tasks/PRs assigned to them by somebody else". It is quite possible
> or likely that these members are eager to see new features, new
> functionalities, or new code added to the project because they get excited
> by such things. You need to take into account the mindset of people who are
> submitting PRs to add a new functionality or fix a bug. The PR author's
> focus correctly is on addressing that particular JIRA and ensuring that
> JIRA gets resolved at the highest quality. To burden that PR author with
> unrelated considerations of build systems, vulnerability findings and such
> is not fair. Note that the project is (or should be) primarily driven by
> users (and customers in case of vendors shipping this code in products) who
> use these features and pay for these features. So we need to balance the
> long term concerns about "security issues" and quality with the immediate
> term concerns about adding features and functionalities.
>
>
>
>>> Also I also strongly feel, we need to be meticulous and think it through
>>> before introducing such checks for reasons discussed before.
>>>
>> +1. Equally applies to a newly introduced functionality and bug fixes.
>>
> Totally agree. However when we discuss or "think through" any concerns they
> should apply to the issue at hand (i.e. the newly introduced functionality
> and bug fixes) and not external factors.
>
>
>>> -Priyanka
>>>
>>>