Check is fine as long as we can identify whether the CVE was introduced by a PR. It might still be useful to fix a CVE even if there is no release, downstream projects might be able to use it.
On Thu, Nov 2, 2017 at 4:42 PM, Thomas Weise <t...@apache.org> wrote: > Check as part of PR build is needed to ensure no new issues are introduced. > I don't think it is necessary to have another build to notice pre-existing > issues since releases won't occur without prior PRs. > > Whitelisting suggestion is for pre-existing problems and not for those > introduced by a PR. > > > On Thu, Nov 2, 2017 at 11:35 PM, Pramod Immaneni <pra...@datatorrent.com> > wrote: > > > If the PR introduces a CVE by all means lets fail it initally and later > > look at whitelisting it if needed. Why fail all PRs that haven't caused > the > > problem. What happens when there are no PRs in a given period, wouldn't > it > > be better to know above crtiical CVEs (that this proposal is trying to > > address) sooner than wait till some random PR is raised. What if there > are > > no PRs for a month. I think it makes sense to have a separate build that > > will catch these errors. > > > > On Thu, Nov 2, 2017 at 3:17 PM, Ananth G <ananthg.a...@gmail.com> wrote: > > > > > Only the first PR should be broken if cve with a higher score than > agreed > > > is introduced .Once you whitelist subsequent builds will not fail? > > > > > > > - The dependency check plugin is enabled to fail/break the build if a > > > violation is detected > > > - A PR introducing a risk will either “acknowledge” the cve by creating > > > the whitelist entry as part of the process or will break the build > > > - The reviewer/s would notice either the changes to the whitelist file > or > > > the build break > > > - The review process would agree upon the approach and ensure JIRA > ticket > > > creation or question why an alternative cannot be used > > > - whitelist would be maintained in a suppressions file example given > here > > > https://jeremylong.github.io/DependencyCheck/general/suppression.html > > > - subsequent PR update should no longer break the build > > > - there is a list of JIRA items for cve which needs to be addressed in > > the > > > subsequent releases as well as a set of artefacts in the project > modules > > > that summarise the community’s awareness of the issue. > > > > > > > > > Regards > > > Ananth > > > > > > > On 3 Nov 2017, at 8:38 am, Pramod Immaneni <pra...@datatorrent.com> > > > wrote: > > > > > > > > The question is which build? We can definitely make it a mandatory > > > release > > > > step and also have nightly builds that are meant for just these, > > > detection > > > > of CVEs and even possible infra changes that might break tests. Those > > > will > > > > work even if there are no PRs. > > > > > > > >> On Thu, Nov 2, 2017 at 1:21 PM, Ananth G <ananthg.a...@gmail.com> > > > wrote: > > > >> > > > >> My vote would be to break the build. This can then force a > > > “whitelisting” > > > >> configuration in the maven plugin to be created as part of the > review > > > >> process ( along with a new JIRA ticket ). > > > >> > > > >> The concern would then be to ensure that the community works > towards a > > > >> resolution of the JIRA. Not breaking the build for me is tech debt > > > slipping > > > >> without anyones notice. Fixing the JIRA is a hygiene process which > I > > > >> believe cannot take a back burner as compared contributor welfare > and > > > would > > > >> need commitments from the contributor ( and/or others). > > > >> > > > >> On a related note, looking at apache spark, there seems to be CVE > > > listings > > > >> which the spark community has taken care of as the releases > > progressed. > > > >> http://www.cvedetails.com/vulnerability-list/vendor_id- > > > >> 45/product_id-38954/Apache-Spark.html <http://www.cvedetails.com/ > > > >> vulnerability-list/vendor_id-45/product_id-38954/Apache-Spark.html> > . > > > >> > > > >> Regards, > > > >> Ananth > > > >> > > > >> > > > >>> On 3 Nov 2017, at 4:48 am, Sanjay Pujare <san...@datatorrent.com> > > > wrote: > > > >>> > > > >>> 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. > > > >>>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >> > > > >> > > > > > >
