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 Thu, 26 Oct 2017 07:08:41 GMT
There is a way to add an exception, but it needs to be discussed on a 
case by case basis. Note that CVEs are not published until a fix is 
available. For severity 8 CVEs I expect patches to become available for 
the reported version unless it is an obsolete version in which case, the 
upgrade to a supported version is already overdue.

I don't see how reporting helps. If a build succeeds, I don't expect 
anyone to look into the report, it is only when CI build fails, 
committers and reviewers look into the details.

IMO, it does not matter how CVE is introduced. It may be a new 
dependency with an existing CVE or it can be a new CVE for an existing 
dependency. In both cases, dependency with the CVE needs to be fixed.

Thank you,


On 10/25/17 11:58, Pramod Immaneni wrote:
> Thanks that sounds mostly fine except what happens if there is a cve
> matching that severity in a dependency but it doesnt affect us because
> let's say we don't exercise that part of functionality *and* there isn't a
> fix available or there is a fix but the upgrade requires significant effort
> (for example if we need to move to a new major version of the dependency or
> something like that). Is there a way to add an exception like we did for
> checkstyle in the interim. How about reporting instead of failing the
> builds. One of the steps in release process could be to investigate these
> reports before proceeding with the release. If a PR introduces new cves by
> virtue of adding a new dependency or changing an existing version, that
> would be of interest and can be subject to failure. Is there a way to
> distinguish that?
> On Wed, Oct 25, 2017 at 8:52 AM Vlad Rozov <vrozov@apache.org> wrote:
>> A CVE (should there be a vulnerability in existing or a newly introduced
>> dependency) will not be exposed during the CI build, but the build will
>> fail if the CVE has severity 8 or above. To get the details, it will be
>> necessary to run dependency check manually.
>> Thank you,
>> Vlad
>> On 10/24/17 16:27, Pramod Immaneni wrote:
>>> There was a lot of discussion on this but looks like there was no final
>>> agreement. Can you summarize what your PR does? Are we disclosing the
>>> actual vulnerabilities as part of the automated build for every PR? That
>>> would be a no-no for me. If it is something that requires manual steps,
>> for
>>> example as part of a release build, that would be fine.
>>> On Mon, Oct 23, 2017 at 1:16 PM, Vlad Rozov <vrozov@apache.org> wrote:
>>>> Please see https://github.com/apache/apex-core/pull/585 and
>> APEXCORE-790.
>>>> Thank you,
>>>> Vlad
>>>> On 9/14/17 09:35, Vlad Rozov wrote:
>>>>> Do you expect anything else from the community to recognize a
>>>>> contribution other than committing it to the code line? Once there is
>>>>> steady flow of quality contributions, the community/PMC will recognize
>> a
>>>>> contributor by making that contributor a committer.
>>>>> Thank you,
>>>>> Vlad
>>>>> On 9/12/17 13:05, Sanjay Pujare wrote:
>>>>>> For a vendor too, quality ought to be as important as security so
>> don't
>>>>>> think we disagree on the cost benefit analysis. But I get your drift.
>>>>>> By "creative incentive" I didn't imply any material incentive
>> (although a
>>>>>> gift card would be nice :-)) but more along the lines of what a
>> community
>>>>>> can do to recognize such contribution.
>>>>>> Sanjay
>>>>>> On Tue, Sep 12, 2017 at 8:10 AM, Vlad Rozov <vrozov@apache.org>
>> wrote:
>>>>>> 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
>> 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
>>>>>>> Thank you,
>>>>>>> Vlad
>>>>>>> On 9/11/17 23:58, Sanjay Pujare wrote:
>>>>>>> I don't want to speak for others and I don't want to generalize.
>> 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.

View raw message