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