I believe the cost will be higher as it won't be like checkstyle where we establish a baseline because these are external dependencies and I am sure vulnerabilities are being reported all the time. I don't mind trying this out with release as the checkpoint where these issues need to be addressed if not resolved but not every build. We should still come up with some guidelines so that this doesn't become a long term blocking activity when we do this at release time.
On Fri, Sep 8, 2017 at 3:33 PM, Thomas Weise <t...@apache.org> wrote: > If it's possible to record exclusions for issues identified as irrelevant > (similar to rat/license check), then after paying the initial cost it will > be incremental effort if and when something changes. > > > On Fri, Sep 8, 2017 at 3:21 PM, Pramod Immaneni <pra...@datatorrent.com> > wrote: > > > Manually during release is fine but we do need to come up with a process > to > > shorten the cycle it will take to address these. Maybe we can come up > > with some guidelines on how to identify when something does not affect > the > > software, for example, if a vulnerability comes into picture when a > > particular library is used in some way and we don't use it that way. It > > could serve as an initial filter and those that make it out of that will > > need deeper analysis to figure out whether they are real issues. > > > > Thanks > > > > On Fri, Sep 8, 2017 at 3:10 PM, Thomas Weise <t...@apache.org> wrote: > > > > > On Fri, Sep 8, 2017 at 2:33 PM, Pramod Immaneni < > pra...@datatorrent.com> > > > wrote: > > > > > > > Second and more importantly, the vulnerabilities cannot be > > > > reported in a public way which integrating with the open build > systems > > > will > > > > do. > > > > > > > > > How about implementing it so that it can be run manually, for example > as > > > part of a release? > > > > > > False alarms are a problem, but ultimately relevant vulnerabilities > will > > > need to be identified and fixed. It's part of project maintenance (like > > CI > > > and other times), which cannot be neglected. > > > > > >
