apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjay Pujare <san...@datatorrent.com>
Subject Re: checking dependencies for known vulnerabilities
Date Fri, 08 Sep 2017 23:42:44 GMT
I am with Pramod on this one.

Are there examples (Apache projects) where PRs are automatically rejected
based on builds flagging CVEs?

On Fri, Sep 8, 2017 at 4:21 PM, Pramod Immaneni <pramod@datatorrent.com>
wrote:

> There are a couple of things here. You may be hard pressed to find software
> with no CVE vulnerabilities as security issues are found all the time so we
> should go with a guideline that is in the spirit of "let's discuss this
> addition and weigh the pros and cons" rather than "don't add whatsoever if
> you find a vulnerability". Almost every software out there has
> vulnerabilities including your OS, hadoop and the various other
> dependencies.
>
> I am fine with the build failing for a PR that has a newly added dependency
> which has CVEs as long as we don't penalize PRs that have nothing to do
> with a dependency change, i.e., don't fail builds for PRs because a new CVE
> was discovered in existing dependencies. Also, if there is a PR with a new
> dependency that has CVEs, let it not be an automatic disqualifier but
> should be discussed on the dev list.
>
> Thanks
>
> On Fri, Sep 8, 2017 at 3:51 PM, Vlad Rozov <vrozov@apache.org> wrote:
>
> > +1 that PR with newly introduced vulnerability should not be merged.
> > Actually, my preference will be that such PR should not be even open.
> >
> > Thank you,
> >
> > Vlad
> >
> >
> > On 9/8/17 15:44, Thomas Weise wrote:
> >
> >> On Fri, Sep 8, 2017 at 3:36 PM, Pramod Immaneni <pramod@datatorrent.com
> >
> >> wrote:
> >>
> >> Though I like the functionality of being able to detect if a new
> >>> dependency
> >>> being added has vulnerabilities and prompting the search for a better
> >>> version, I am wary of tying a build strongly to vulnerability detection
> >>> i.e., the build failing when vulnerabilities are discovered in
> >>> dependencies. This immediately blocks our project till those
> >>> vulnerabilities are addressed as nothing can go in because builds are
> >>> failing. If details are suppressed and we have a summary warning but
> not
> >>> fail the build, that should be ok.
> >>>
> >>>
> >>> I think that if a new problem is introduced, then it should be
> discovered
> >> in the CI and the PR that causes it not be merged until it is addressed.
> >>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message