I like this suggestion. Blocking the PR is too drastic. I also second Pramod's point (made elsewhere) that we should try to encourage contribution instead of discouraging it by resorting to drastic measures. If you institute drastic measures to achieve a desired effect (e.g. getting contributors to look into CVEs and build infrastructure issues) it can have the opposite effect of contributors losing interest.
Sanjay On Wed, Nov 1, 2017 at 1:25 PM, Thomas Weise <t...@apache.org> wrote: > Considering typical behavior, unless the CI build fails, very few will be > interested fixing the issues. > > Perhaps if after a CI failure the issue can be identified as pre-existing, > we can whitelist and create a JIRA that must be addressed prior to the next > release? > > > On Wed, Nov 1, 2017 at 7:51 PM, Pramod Immaneni <pra...@datatorrent.com> > wrote: > > > I would like to hear what others think.. at this point I am -1 on merging > > the change as is that would fail all PR builds when a matching CVE is > > discovered regardless of whether the PR was the cause of the CVE or not. > > > > On Wed, Nov 1, 2017 at 12:07 PM, Vlad Rozov <vro...@apache.org> wrote: > > > > > On 11/1/17 11:39, Pramod Immaneni wrote: > > > > > >> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vro...@apache.org> > wrote: > > >> > > >> There is no independent build and the check is still necessary to > > prevent > > >>> new dependencies with CVE being introduced. > > >>> > > >>> There isn't one today but one could be added. What kind of effort is > > >> needed. > > >> > > > After it is added, we can discuss whether it will make sense to move > the > > > check to the newly created build. Even if one is added, the check needs > > to > > > be present in the CI builds that verify PR, so it is in the right place > > > already, IMO. > > > > > >> > > >> > > >> Look at Malhar 3.8.0 thread. There are libraries from Category X > > >>> introduced as a dependency, so now instead of dealing with the issue > > when > > >>> such dependencies were introduced, somebody else needs to deal with > > >>> removing/fixing those dependencies. > > >>> > > >>> Those were directly introduced in PRs. I am not against adding > > additional > > >> checks that verify the PR better. > > >> > > > Right and it would be much better to catch the problem at the time it > was > > > introduced, but Category X list (as well as known CVE) is not static. > > > > > > > > >> > > >> Thank you, > > >>> > > >>> Vlad > > >>> > > >>> > > >>> On 11/1/17 11:21, Pramod Immaneni wrote: > > >>> > > >>> My original concern still remains. I think what you have is valuable > > but > > >>>> would prefer that it be activated in an independent build that > > notifies > > >>>> the > > >>>> interested parties. > > >>>> > > >>>> On Wed, Nov 1, 2017 at 11:13 AM, Vlad Rozov <vro...@apache.org> > > wrote: > > >>>> > > >>>> Any other concerns regarding merging the PR? By looking at the > active > > >>>> PRs > > >>>> > > >>>>> on the apex core the entire conversation looks to be at the moot > > point. > > >>>>> > > >>>>> Thank you, > > >>>>> > > >>>>> Vlad > > >>>>> > > >>>>> > > >>>>> On 10/30/17 18:50, Vlad Rozov wrote: > > >>>>> > > >>>>> On 10/30/17 17:30, Pramod Immaneni wrote: > > >>>>> > > >>>>>> On Sat, Oct 28, 2017 at 7:47 AM, Vlad Rozov <vro...@apache.org> > > >>>>>> wrote: > > >>>>>> > > >>>>>>> Don't we use unit test to make sure that PR does not break an > > >>>>>>> existing > > >>>>>>> > > >>>>>>> functionality? For that we use CI environment that we do not > > control > > >>>>>>>> and do > > >>>>>>>> not introduce any changes to, but for example Apache > > infrastructure > > >>>>>>>> team > > >>>>>>>> may decide to upgrade Jenkins and that may impact Apex builds. > The > > >>>>>>>> same > > >>>>>>>> applies to CVE. It is there to prevent dependencies with severe > > >>>>>>>> vulnerabilities. > > >>>>>>>> > > >>>>>>>> Infrastructure changes are quite different, IMO, from this > > proposal. > > >>>>>>>> > > >>>>>>>> While > > >>>>>>> they are not in our control, in majority of the cases, the > changes > > >>>>>>> maintain > > >>>>>>> compatibility so everything on top will continue to run the same. > > In > > >>>>>>> this > > >>>>>>> case a CVE will always fail all PRs, the code changes have > nothing > > to > > >>>>>>> do > > >>>>>>> with introducing the CVE. I did make the exception that if a PR > is > > >>>>>>> bringing > > >>>>>>> in the CVE yes do fail it. > > >>>>>>> > > >>>>>>> There were just two recent changes, one on Travis CI side and > > another > > >>>>>>> > > >>>>>> on > > >>>>>> Jenkins side that caused builds for all PRs to fail and none of > them > > >>>>>> was > > >>>>>> caused by code changes in any of open PRs, so I don't see how it > is > > >>>>>> different. > > >>>>>> > > >>>>>> A code change may or may not have relation to CVE introduced. For > > >>>>>> newly > > >>>>>> introduced dependencies, there may be known CVEs. In any case I > > don't > > >>>>>> think > > >>>>>> it is important to differentiate how CVE is introduced, it is > > >>>>>> important > > >>>>>> to > > >>>>>> eliminate dependencies with known CVEs. > > >>>>>> > > >>>>>> > > >>>>>> There is no "stick" in a failed build or keeping PR open until > > >>>>>>> dependency > > >>>>>>> > > >>>>>>> issue is resolved or unit test failure is fixed. Unless an > employer > > >>>>>>>> punishes its employee for not delivering PR based on that vendor > > >>>>>>>> priority, > > >>>>>>>> there is no "stick". As we already discussed, the community does > > not > > >>>>>>>> have a > > >>>>>>>> deadline for a PR merge or for a release to go out. In a case > > there > > >>>>>>>> is a > > >>>>>>>> problematic dependency (with CVE or category X license) you as a > > PMC > > >>>>>>>> suppose to -1 a release (at least I will). Will you consider -1 > > as a > > >>>>>>>> "stick"? For me, it is not about punishing an individual > > >>>>>>>> contributor, > > >>>>>>>> it is > > >>>>>>>> a priority and focus shift for the entire community, not a > "stick" > > >>>>>>>> for > > >>>>>>>> an > > >>>>>>>> individual contributor. > > >>>>>>>> > > >>>>>>>> The stick I am referring to is failing all PRs hoping that will > > make > > >>>>>>>> > > >>>>>>>> people > > >>>>>>> address CVEs. It's got nothing to do with an employer, people > > >>>>>>> contributing > > >>>>>>> to open source can't expect they can control what the outcome > will > > be > > >>>>>>> or > > >>>>>>> what form it will take. You may be confusing this with some other > > >>>>>>> issue. > > >>>>>>> In > > >>>>>>> some of the arguments, you are assuming this scenario is similar > to > > >>>>>>> build > > >>>>>>> failures from failing unit tests and I am arguing that premise. I > > >>>>>>> don't > > >>>>>>> think we should bring regular development to a halt whenever a > > >>>>>>> matching > > >>>>>>> CVE > > >>>>>>> is discovered, unless there is some other secondary reason like > > >>>>>>> merging a > > >>>>>>> PR will make it difficult for a CVE fix to be made. Have you > given > > a > > >>>>>>> thought to what I said about having a separate build that will > > notify > > >>>>>>> about > > >>>>>>> CVEs. > > >>>>>>> > > >>>>>>> As I mentioned, there is no stick, no deadlines and no issues > > keeping > > >>>>>>> > > >>>>>> PRs > > >>>>>> open until builds can be verified on CI environment. Fixing a > failed > > >>>>>> build > > >>>>>> is a priority for the *community* not a stick for an individual > > >>>>>> contributor. > > >>>>>> > > >>>>>> I don't see why keeping PRs open (for whatever reason) brings > > regular > > >>>>>> development to a halt. Nobody is going to put github repo offline. > > >>>>>> Contributors may continue to open new PR, collaborate on existing > > PRs > > >>>>>> and > > >>>>>> add more changes (and need to be patient for those changes to be > > >>>>>> reviewed > > >>>>>> and accepted). The regular development will continue with the only > > >>>>>> exception that the next commit to be merged must address the build > > >>>>>> issue > > >>>>>> (whether it is a failed unit test or newly found CVE). > > >>>>>> > > >>>>>> I don't see much value in a separate build and do not plan to put > > >>>>>> effort > > >>>>>> in that direction. Additionally, will not a separate build that > only > > >>>>>> checks > > >>>>>> for CVE will trigger your initial concern of disclosing CVE in > > public? > > >>>>>> > > >>>>>> Thank you, > > >>>>>> > > >>>>>>> Vlad > > >>>>>>> > > >>>>>>>> > > >>>>>>>> On 10/27/17 14:28, Pramod Immaneni wrote: > > >>>>>>>> > > >>>>>>>> On Fri, Oct 27, 2017 at 11:51 AM, Vlad Rozov <vro...@apache.org > > > > >>>>>>>> wrote: > > >>>>>>>> > > >>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote: > > >>>>>>>>> > > >>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov < > vro...@apache.org> > > >>>>>>>>> > > >>>>>>>>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>> I guess you are mostly concerned regarding new CVE in an > > existing > > >>>>>>>>>> > > >>>>>>>>>>> dependency. Once such CVE is added to a database, will it be > > >>>>>>>>>>> better > > >>>>>>>>>>> > > >>>>>>>>>>> to > > >>>>>>>>>>>> know > > >>>>>>>>>>>> about it or postpone discovery till we cut release > candidate? > > In > > >>>>>>>>>>>> case > > >>>>>>>>>>>> it > > >>>>>>>>>>>> is > > >>>>>>>>>>>> reported only during release cycle, there is much less time > > for > > >>>>>>>>>>>> the > > >>>>>>>>>>>> community to take an action and it still needs to be taken > > (as a > > >>>>>>>>>>>> PMC > > >>>>>>>>>>>> member > > >>>>>>>>>>>> you are responsible for preventing release with severe > > security > > >>>>>>>>>>>> issue > > >>>>>>>>>>>> going > > >>>>>>>>>>>> out). If it is reported once the information becomes > > available, > > >>>>>>>>>>>> there > > >>>>>>>>>>>> is > > >>>>>>>>>>>> more time to research and either upgrade the dependency with > > >>>>>>>>>>>> newly > > >>>>>>>>>>>> found > > >>>>>>>>>>>> CVE, agree that it does not impact the project. > > >>>>>>>>>>>> > > >>>>>>>>>>>> This would be the more commonly occurring scenario. We can > > >>>>>>>>>>>> always > > >>>>>>>>>>>> know > > >>>>>>>>>>>> > > >>>>>>>>>>>> about the CVEs because of your changes. We don't need to > fail > > >>>>>>>>>>>> > > >>>>>>>>>>>> builds to > > >>>>>>>>>>> do > > >>>>>>>>>>> that. I am not asking you to remove the reporting. There is > no > > >>>>>>>>>>> set > > >>>>>>>>>>> time > > >>>>>>>>>>> for > > >>>>>>>>>>> a release so having less time during release for addressing > > >>>>>>>>>>> relevant > > >>>>>>>>>>> CVEs > > >>>>>>>>>>> does not come up. There is also nothing preventing anyone > from > > >>>>>>>>>>> looking > > >>>>>>>>>>> at > > >>>>>>>>>>> these reports and taking action earlier. > > >>>>>>>>>>> > > >>>>>>>>>>> I don't see why it will be more commonly occurring scenario, > > but > > >>>>>>>>>>> I > > >>>>>>>>>>> think > > >>>>>>>>>>> > > >>>>>>>>>>> it is equally important to prevent new dependency with severe > > >>>>>>>>>>> > > >>>>>>>>>> vulnerabilities being introduced into the project and check > > >>>>>>>>>> existing > > >>>>>>>>>> dependencies for newly discovered severe vulnerabilities. > > >>>>>>>>>> > > >>>>>>>>>> How will we know about CVE if it is removed from CI build? Why > > >>>>>>>>>> require > > >>>>>>>>>> manual verification when it can be done during CI build and > does > > >>>>>>>>>> not > > >>>>>>>>>> affect > > >>>>>>>>>> builds done by individual contributors? > > >>>>>>>>>> > > >>>>>>>>>> While there is no set time for a release, there is no set time > > >>>>>>>>>> for a > > >>>>>>>>>> PR > > >>>>>>>>>> merge as well. > > >>>>>>>>>> > > >>>>>>>>>> Yes, nothing prevents anyone from looking at the dependency > > >>>>>>>>>> vulnerabilities, but there is a better chance that "anyone" > does > > >>>>>>>>>> not > > >>>>>>>>>> mean > > >>>>>>>>>> nobody if CI build fails. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> I still do not understand why you value an individual > > contributor > > >>>>>>>>>> and > > >>>>>>>>>> > > >>>>>>>>>> PR > > >>>>>>>>>>> > > >>>>>>>>>>> over the community and the project itself. Once there is a > > severe > > >>>>>>>>>>> > > >>>>>>>>>>> security > > >>>>>>>>>>>> vulnerability, it affects everyone who cares about the > > project, > > >>>>>>>>>>>> including > > >>>>>>>>>>>> all contributors. I don't see a problem with a PR being in a > > >>>>>>>>>>>> pending > > >>>>>>>>>>>> (not > > >>>>>>>>>>>> merged) open state till a build issue is resolved. > > >>>>>>>>>>>> > > >>>>>>>>>>>> That is a mischaracterization that you have stated before as > > >>>>>>>>>>>> well. A > > >>>>>>>>>>>> > > >>>>>>>>>>>> project cannot grow without contributions and without > policies > > >>>>>>>>>>>> that > > >>>>>>>>>>>> > > >>>>>>>>>>>> create > > >>>>>>>>>>> a supportive enviroment where that can happen, I don't see > the > > >>>>>>>>>>> need > > >>>>>>>>>>> to > > >>>>>>>>>>> put > > >>>>>>>>>>> unnecessary obstacles for legitimate contributions that are > not > > >>>>>>>>>>> the > > >>>>>>>>>>> cause > > >>>>>>>>>>> of a problem. Everytime there is a matching CVE the PRs are > > going > > >>>>>>>>>>> to > > >>>>>>>>>>> get > > >>>>>>>>>>> blocked till that CVE is addressed and I am not confident we > > have > > >>>>>>>>>>> the > > >>>>>>>>>>> bandwidth in the community to address this expediently. It is > > >>>>>>>>>>> also > > >>>>>>>>>>> inaccurate to equate this to PR not being merged till build > > >>>>>>>>>>> issues > > >>>>>>>>>>> are > > >>>>>>>>>>> resolved as it derives from an assumption that CVE is same > as a > > >>>>>>>>>>> build > > >>>>>>>>>>> failure. > > >>>>>>>>>>> > > >>>>>>>>>>> While project can't grow without individual contributions, > > >>>>>>>>>>> project > > >>>>>>>>>>> is a > > >>>>>>>>>>> > > >>>>>>>>>>> result of a large number of contributions from a number of > > >>>>>>>>>>> > > >>>>>>>>>> contributors. > > >>>>>>>>>> Some of those contributors are not active anymore and will not > > >>>>>>>>>> provide > > >>>>>>>>>> any > > >>>>>>>>>> fixes should a vulnerability be found in their contribution. > It > > >>>>>>>>>> becomes a > > >>>>>>>>>> shared responsibility of all currently active community > members > > >>>>>>>>>> and > > >>>>>>>>>> those > > >>>>>>>>>> who submit PR are part of the community and share that > > >>>>>>>>>> responsibility, > > >>>>>>>>>> are > > >>>>>>>>>> not they? If a contributor considers him/herself as part of a > > >>>>>>>>>> community, > > >>>>>>>>>> why he or she can't wait for the build issue to be resolved or > > >>>>>>>>>> better > > >>>>>>>>>> take > > >>>>>>>>>> an action on resolving the issue? The only possible > explanation > > >>>>>>>>>> that I > > >>>>>>>>>> see > > >>>>>>>>>> is the one that I already mentioned on this thread. > > >>>>>>>>>> > > >>>>>>>>>> If you see this as unnecessary obstacles for legitimate > > >>>>>>>>>> contributions, > > >>>>>>>>>> why > > >>>>>>>>>> to enforce code style, it is also unnecessary obstacle. Unit > > test? > > >>>>>>>>>> Should > > >>>>>>>>>> it be considered to be optional for a PR to pass unit tests as > > >>>>>>>>>> well? > > >>>>>>>>>> What > > >>>>>>>>>> if an environment change on CI side causes build to fail > similar > > >>>>>>>>>> to > > >>>>>>>>>> what > > >>>>>>>>>> happened recently? Should we disable CI builds too and rely > on a > > >>>>>>>>>> committer > > >>>>>>>>>> or a release manager to run unit tests? If CI build fails for > > >>>>>>>>>> whatever > > >>>>>>>>>> reason, how can you be sure that if it fails for another PR as > > >>>>>>>>>> well, > > >>>>>>>>>> that > > >>>>>>>>>> they both fail for the same reason and there is no any other > > >>>>>>>>>> reasons > > >>>>>>>>>> that > > >>>>>>>>>> will cause a problem with a PR? > > >>>>>>>>>> > > >>>>>>>>>> I don't know how failing PRs because of CVE, which we don't > > >>>>>>>>>> introduce, > > >>>>>>>>>> > > >>>>>>>>>> don't control, no idea of and possibly unrelated would fall in > > the > > >>>>>>>>> same > > >>>>>>>>> bucket as unit tests. I am at a loss of words for that. There > is > > no > > >>>>>>>>> reason > > >>>>>>>>> to block legitimate development for this. This can be handled > > >>>>>>>>> separtely > > >>>>>>>>> and > > >>>>>>>>> in parallel. Maybe there is a way we can setup an independent > job > > >>>>>>>>> on > > >>>>>>>>> a > > >>>>>>>>> build server that runs nightly, fails if there are new CVEs > > >>>>>>>>> discovered > > >>>>>>>>> and > > >>>>>>>>> sends an email out to the security or dev group. You could even > > >>>>>>>>> reduce > > >>>>>>>>> the > > >>>>>>>>> CVE threshold for this. I don't believe in a stick approach > > (carrot > > >>>>>>>>> and > > >>>>>>>>> stick metaphor) and believe in proportional measures. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Thank you, > > >>>>>>>>> > > >>>>>>>>> Vlad > > >>>>>>>>>> > > >>>>>>>>>>> On 10/26/17 09:42, Pramod Immaneni wrote: > > >>>>>>>>>>>> > > >>>>>>>>>>>> On Thu, Oct 26, 2017 at 12:08 AM, Vlad Rozov < > > vro...@apache.org > > >>>>>>>>>>>> > > > >>>>>>>>>>>> wrote: > > >>>>>>>>>>>> > > >>>>>>>>>>>> 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 think we should retain the ability to make that choice > of > > >>>>>>>>>>>>>> what > > >>>>>>>>>>>>>> and > > >>>>>>>>>>>>>> when > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> to upgrade rather than hard enforce it. Like I mentioned > the > > >>>>>>>>>>>>>> CVE > > >>>>>>>>>>>>>> may > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> not > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>> apply to us (it has happened before), even though it may be > > >>>>>>>>>>>>> beneficial > > >>>>>>>>>>>>> upgrade generally when its not applicable, there may not be > > the > > >>>>>>>>>>>>> bandwidth > > >>>>>>>>>>>>> in community to do the necessary changes to upgrade to a > > newer > > >>>>>>>>>>>>> version > > >>>>>>>>>>>>> especially if those dependencies don't follow semver (has > > >>>>>>>>>>>>> happened > > >>>>>>>>>>>>> before > > >>>>>>>>>>>>> as well, remember effort with ning). My caution comes from > > >>>>>>>>>>>>> experiencing > > >>>>>>>>>>>>> this situation before. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> 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. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> We can add a mandatory step during release that we need to > > >>>>>>>>>>>>>> assess > > >>>>>>>>>>>>>> CVEs > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> matching this criteria before proceeding with the release. > > >>>>>>>>>>>>>> This > > >>>>>>>>>>>>>> could > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> end > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>> up requiring upgrade of some dependencies and in other > cases > > it > > >>>>>>>>>>>>> may > > >>>>>>>>>>>>> not > > >>>>>>>>>>>>> be > > >>>>>>>>>>>>> needed. This assessment can also happen more often in adhoc > > >>>>>>>>>>>>> fashion > > >>>>>>>>>>>>> offline > > >>>>>>>>>>>>> before release based upon interest from community. I am > also > > >>>>>>>>>>>>> open > > >>>>>>>>>>>>> to > > >>>>>>>>>>>>> making > > >>>>>>>>>>>>> it mandatory with every PR, in future, like you are > > suggesting, > > >>>>>>>>>>>>> if > > >>>>>>>>>>>>> we > > >>>>>>>>>>>>> see > > >>>>>>>>>>>>> sufficient uptake in community on these issues. From > > experience > > >>>>>>>>>>>>> this > > >>>>>>>>>>>>> is > > >>>>>>>>>>>>> not > > >>>>>>>>>>>>> there currently and hence I don't want to do this now. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> 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. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> In one case the PR is not directly responsible for the > issue > > >>>>>>>>>>>>>> and > > >>>>>>>>>>>>>> hence > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> we > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> should avoid penalizing them or block them. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Thank you, > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Vlad > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> 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 < > > >>>>>>>>>>>>>>> vro...@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 < > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> vro...@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 > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> a > > >>>>>>>>>>>>>>>>>>> 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 > > >>>>>>>>>>>>>>>>>>> I > > >>>>>>>>>>>>>>>>>>> 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 < > > >>>>>>>>>>>>>>>>>> vro...@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 > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> 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 > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> it. > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> 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. > > >>>>>>>>>>>>>>>>>>>>> But > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> 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. > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > > > > >
