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