apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vlad Rozov <vro...@apache.org>
Subject Re: checking dependencies for known vulnerabilities
Date Tue, 12 Sep 2017 15:10:44 GMT
I guess we have a different view on the benefit and cost definition. For 
me the benefit of fixing CI build, flaky unit test, severe security 
issue is huge for the community and is possibly small (except for a 
security issues) for a vendor.

By "creative" I hope you don't mean that other community members, users 
and customers send a contributor a gift cards to compensate for the cost 
:). For me PR that is blocked on a failed CI build is sufficiently 
incentive for a contributor to look into why it fails and fixing it.

Thank you,


On 9/11/17 23:58, Sanjay Pujare wrote:
> I don't want to speak for others and I don't want to generalize. But an
> obvious answer could be "cost-benefit analysis".
> In any case we should come up with a creative way to "incentivize" members
> to do these tasks.
> On Mon, Sep 11, 2017 at 10:59 PM, Vlad Rozov <vrozov@apache.org> wrote:
>> 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
>>>>> 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

View raw message