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 <vro...@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 <pra...@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. >> >> >
