checking dependencies for known vulnerabilities

[Vlad Rozov <v....@gmail.com>]

Any objections to implementing 
https://www.owasp.org/index.php/OWASP_Dependency_Check maven plugin that 
will run on Travis/Jenkins and check for known vulnerabilities?

Thank you,

Vlad

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

Can we build a way into CI to distinguish between these and a new
vulnerability that has come up in an unchanged dependency?

On Fri, Sep 8, 2017 at 3:44 PM, Thomas Weise <th...@apache.org> wrote:

> On Fri, Sep 8, 2017 at 3:36 PM, Pramod Immaneni <pr...@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.
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

I don't see why it will be beneficial for the community to do something 
manually when it can be automated.

Thank you,

Vlad

On 11/1/17 17:09, Munagala Ramanath wrote:
>   Failing the CI build seems too drastic. My suggestion is to create a new profile that activates thisfunctionality and encourage people to run with this profile and file JIRAs when somethingexciting happens.
> Ram
>      On Wednesday, November 1, 2017, 1:26:00 PM PDT, Thomas Weise <th...@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 <pr...@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 <vr...@apache.org> wrote:
>>
>>> On 11/1/17 11:39, Pramod Immaneni wrote:
>>>
>>>> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@apache.org>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>>>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vr...@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 <
>> vrozov@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 <
>>>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>> vrozov@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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>    

Re: checking dependencies for known vulnerabilities

[Munagala Ramanath <am...@yahoo.com.INVALID>]

 Failing the CI build seems too drastic. My suggestion is to create a new profile that activates thisfunctionality and encourage people to run with this profile and file JIRAs when somethingexciting happens.
Ram
    On Wednesday, November 1, 2017, 1:26:00 PM PDT, Thomas Weise <th...@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 <pr...@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 <vr...@apache.org> wrote:
>
> > On 11/1/17 11:39, Pramod Immaneni wrote:
> >
> >> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@apache.org>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
> >>>>>>>>>
> >>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vr...@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 <
> vrozov@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 <
> >>>>>>>>>>>>>>> vrozov@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 <
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> vrozov@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 <
> >>>>>>>>>>>>>>>>>> vrozov@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.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >
>
  

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

Do you mean that blocking my PR 
https://github.com/apache/apex-core/pull/585 is too drastic? I fully 
agree :). Why not to apply the same rule to that PR?

Will you agree that somebody needs to look into CVE, build issues or 
failed unit tests? If yes, who is that "somebody" is?

Let me give you another example. I'd like to contribute unit test 
log4j.properties cleanup (https://github.com/apache/apex-core/pull/584), 
but it fails due to incorrect assumptions done in LoggerUtilTest and 
LogFileInformationTest. Would you expect me to fix those assumptions or 
simply disable unit test?

Thank you,

Vlad

On 11/2/17 10:48, Sanjay Pujare 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 <th...@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 <pr...@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 <vr...@apache.org> wrote:
>>>
>>>> On 11/1/17 11:39, Pramod Immaneni wrote:
>>>>
>>>>> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vrozov@apache.org
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>>>>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <
>> vrozov@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 <
>>> vrozov@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 <
>>>>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>>> vrozov@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.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

There is no question of which build as there is only one build. Once 
somebody puts an effort to create nightly build we can discuss moving 
the check from the current build to the nightly build, but then the 
question will be what do we do with PR that introduces new dependencies 
with CVE? Remember that goal of the PR is to prevent dependencies with 
severe CVE being introduced into the project and also to prevent 
technical debt at the time of a release.

Thank you,

Vlad

On 11/2/17 14:38, Pramod Immaneni 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 <an...@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 <sa...@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 <th...@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 <pramod@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 <vr...@apache.org> wrote:
>>>>>
>>>>>> On 11/1/17 11:39, Pramod Immaneni wrote:
>>>>>>
>>>>>>> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <
>> vrozov@apache.org
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>>>>>>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <
>>>> vrozov@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 <
>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>>>>> vrozov@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.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>

Re: checking dependencies for known vulnerabilities

[Thomas Weise <th...@apache.org>]

After the PR CI build fails it should be straightforward to see if the
dependency was part of the PR or not.


On Thu, Nov 2, 2017 at 11:50 PM, Pramod Immaneni <pr...@datatorrent.com>
wrote:

> 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 <th...@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 <pramod@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 <an...@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 <pramod@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 <an...@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 <sanjay@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 <th...@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 <
> > > > pramod@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 <
> vrozov@apache.org>
> > > > wrote:
> > > > >>>>>>
> > > > >>>>>>> On 11/1/17 11:39, Pramod Immaneni wrote:
> > > > >>>>>>>
> > > > >>>>>>> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <
> vrozov@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 <
> > vrozov@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 <
> > > vrozov@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 <
> > > > >> vrozov@apache.org
> > > > >>>>>
> > > > >>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <
> > > > >>>> vrozov@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 <
> > > > >>>>> vrozov@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 <
> > > > >>>>>>>>>>>>>>>>>>>> vrozov@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 <
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>> vrozov@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 <
> > > > >>>>>>>>>>>>>>>>>>>>>>> vrozov@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.
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>
> > > > >>
> > > >
> > >
> >
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

Please see PR https://github.com/apache/apex-core/pull/585 comments and 
APEXCORE-790 for the further discussion and the resolution. There is 
still one open item - updating contributor/committer guidelines if 
someone wants to help with it.

Thank you,

Vlad

On 11/2/17 16:55, Vlad Rozov wrote:
> Can you check if there is a possibility to distinguish between 
> existing dependencies and dependencies introduced in a PR. AFAIK, it 
> does not exist.
>
> Thank you,
>
> Vlad
>
> On 11/2/17 16:50, Pramod Immaneni wrote:
>> 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 <th...@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 
>>> <pr...@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 <an...@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 <pr...@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 <an...@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 <sa...@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 <th...@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 <
>>>>> pramod@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 <vr...@apache.org>
>>>>> wrote:
>>>>>>>>>>>> On 11/1/17 11:39, Pramod Immaneni wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vrozov@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 <
>>> vrozov@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 <
>>>> vrozov@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 <
>>>>>>> vrozov@apache.org
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <
>>>>>>>>> vrozov@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 <
>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> vrozov@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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

Can you check if there is a possibility to distinguish between existing 
dependencies and dependencies introduced in a PR. AFAIK, it does not exist.

Thank you,

Vlad

On 11/2/17 16:50, Pramod Immaneni wrote:
> 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 <th...@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 <pr...@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 <an...@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 <pr...@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 <an...@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 <sa...@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 <th...@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 <
>>>> pramod@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 <vr...@apache.org>
>>>> wrote:
>>>>>>>>>>> On 11/1/17 11:39, Pramod Immaneni wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vrozov@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 <
>> vrozov@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 <
>>> vrozov@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 <
>>>>>> vrozov@apache.org
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <
>>>>>>>> vrozov@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 <
>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>> vrozov@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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

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 <th...@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 <pr...@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 <an...@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 <pr...@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 <an...@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 <sa...@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 <th...@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 <
> > > pramod@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 <vr...@apache.org>
> > > wrote:
> > > >>>>>>
> > > >>>>>>> On 11/1/17 11:39, Pramod Immaneni wrote:
> > > >>>>>>>
> > > >>>>>>> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vrozov@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 <
> vrozov@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 <
> > vrozov@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 <
> > > >> vrozov@apache.org
> > > >>>>>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <
> > > >>>> vrozov@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 <
> > > >>>>> vrozov@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 <
> > > >>>>>>>>>>>>>>>>>>>> vrozov@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 <
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> vrozov@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 <
> > > >>>>>>>>>>>>>>>>>>>>>>> vrozov@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.
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>
> > > >>
> > >
> >
>

Re: checking dependencies for known vulnerabilities

[Thomas Weise <th...@apache.org>]

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 <pr...@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 <an...@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 <pr...@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 <an...@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 <sa...@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 <th...@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 <
> > pramod@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 <vr...@apache.org>
> > wrote:
> > >>>>>>
> > >>>>>>> On 11/1/17 11:39, Pramod Immaneni wrote:
> > >>>>>>>
> > >>>>>>> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vr...@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 <vrozov@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 <
> vrozov@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 <
> > >> vrozov@apache.org
> > >>>>>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <
> > >>>> vrozov@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 <
> > >>>>> vrozov@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 <
> > >>>>>>>>>>>>>>>>>>>> vrozov@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 <
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> vrozov@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 <
> > >>>>>>>>>>>>>>>>>>>>>>> vrozov@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.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>
> > >>
> >
>

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

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 <an...@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 <pr...@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 <an...@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 <sa...@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 <th...@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 <
> pramod@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 <vr...@apache.org>
> wrote:
> >>>>>>
> >>>>>>> On 11/1/17 11:39, Pramod Immaneni wrote:
> >>>>>>>
> >>>>>>> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vr...@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 <vr...@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 <vrozov@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 <
> >> vrozov@apache.org
> >>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <
> >>>> vrozov@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 <
> >>>>> vrozov@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 <
> >>>>>>>>>>>>>>>>>>>> vrozov@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 <
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> vrozov@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 <
> >>>>>>>>>>>>>>>>>>>>>>> vrozov@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.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
>

Re: checking dependencies for known vulnerabilities

[Ananth G <an...@gmail.com>]

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 <pr...@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 <an...@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 <sa...@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 <th...@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 <pramod@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 <vr...@apache.org> wrote:
>>>>>> 
>>>>>>> On 11/1/17 11:39, Pramod Immaneni wrote:
>>>>>>> 
>>>>>>> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <
>> vrozov@apache.org
>>>>> 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <
>>>> vrozov@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 <
>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>>>>> vrozov@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.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> 

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

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 <an...@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 <sa...@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 <th...@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 <pramod@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 <vr...@apache.org> wrote:
> >>>
> >>>> On 11/1/17 11:39, Pramod Immaneni wrote:
> >>>>
> >>>>> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <
> vrozov@apache.org
> >>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <
> >> vrozov@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 <
> >>> vrozov@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 <
> >>>>>>>>>>>>>>>>>> vrozov@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 <
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> vrozov@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 <
> >>>>>>>>>>>>>>>>>>>>> vrozov@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.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>
> >>>
> >>
>
>

Re: checking dependencies for known vulnerabilities

[Ananth G <an...@gmail.com>]

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 <sa...@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 <th...@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 <pr...@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 <vr...@apache.org> wrote:
>>> 
>>>> On 11/1/17 11:39, Pramod Immaneni wrote:
>>>> 
>>>>> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vrozov@apache.org
>>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <
>> vrozov@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 <
>>> vrozov@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 <
>>>>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>>>>> vrozov@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.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>> 
>>> 
>> 

Re: checking dependencies for known vulnerabilities

[Sanjay Pujare <sa...@datatorrent.com>]

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 <th...@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 <pr...@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 <vr...@apache.org> wrote:
> >
> > > On 11/1/17 11:39, Pramod Immaneni wrote:
> > >
> > >> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vrozov@apache.org
> >
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
> > >>>>>>>>>
> > >>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <
> vrozov@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 <
> > vrozov@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 <
> > >>>>>>>>>>>>>>> vrozov@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 <
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> vrozov@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 <
> > >>>>>>>>>>>>>>>>>> vrozov@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.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >
> >
>

Re: checking dependencies for known vulnerabilities

[Thomas Weise <th...@apache.org>]

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 <pr...@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 <vr...@apache.org> wrote:
>
> > On 11/1/17 11:39, Pramod Immaneni wrote:
> >
> >> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@apache.org>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
> >>>>>>>>>
> >>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vr...@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 <
> vrozov@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 <
> >>>>>>>>>>>>>>> vrozov@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 <
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> vrozov@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 <
> >>>>>>>>>>>>>>>>>> vrozov@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.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >
>

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

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 <vr...@apache.org> wrote:

> On 11/1/17 11:39, Pramod Immaneni wrote:
>
>> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>>>>>>>>
>>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vr...@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 <vrozov@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 <
>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>>> vrozov@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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

On 11/1/17 11:39, Pramod Immaneni wrote:
> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>>>>>>>
>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <
>>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>>> vrozov@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.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vr...@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.


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


>
> 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 <vr...@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 <vr...@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 <vr...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>>>>>>
>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <
>>>>>>>>>>>>>> vrozov@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 <
>>>>>>>>>>>>>>>> vrozov@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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

There is no independent build and the check is still necessary to 
prevent new dependencies with CVE being introduced.

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.

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 <vr...@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 <vr...@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 <vr...@apache.org> wrote:
>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>>>>>
>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@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 <
>>>>>>>>>>>>>>> vrozov@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.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

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 <vr...@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 <vr...@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 <vr...@apache.org> wrote:
>>>>>
>>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>>>>
>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@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 <
>>>>>>>>>>>>>> vrozov@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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

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 <vr...@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 <vr...@apache.org> 
>>>> wrote:
>>>>
>>>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@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 
>>>>>>>>>>>>> <vr...@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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

On 10/30/17 17:30, Pramod Immaneni wrote:
> On Sat, Oct 28, 2017 at 7:47 AM, Vlad Rozov <vr...@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 <vr...@apache.org> wrote:
>>>
>>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@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 <vr...@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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

On Sat, Oct 28, 2017 at 7:47 AM, Vlad Rozov <vr...@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 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.

Thank you,
>
> Vlad
>
>
> On 10/27/17 14:28, Pramod Immaneni wrote:
>
>> On Fri, Oct 27, 2017 at 11:51 AM, Vlad Rozov <vr...@apache.org> wrote:
>>
>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>>
>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@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 <vr...@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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

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.

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.

Thank you,

Vlad

On 10/27/17 14:28, Pramod Immaneni wrote:
> On Fri, Oct 27, 2017 at 11:51 AM, Vlad Rozov <vr...@apache.org> wrote:
>
>> On 10/26/17 11:46, Pramod Immaneni wrote:
>>
>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@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 <vr...@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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

On Fri, Oct 27, 2017 at 11:51 AM, Vlad Rozov <vr...@apache.org> wrote:

> On 10/26/17 11:46, Pramod Immaneni wrote:
>
>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@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 <vr...@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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

On 10/26/17 11:46, Pramod Immaneni wrote:
> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vr...@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?

>
>
>> Thank you,
>>
>> Vlad
>>
>>
>> On 10/26/17 09:42, Pramod Immaneni wrote:
>>
>>> On Thu, Oct 26, 2017 at 12:08 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@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.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@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 <vr...@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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

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.

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.

Thank you,

Vlad

On 10/26/17 09:42, Pramod Immaneni wrote:
> On Thu, Oct 26, 2017 at 12:08 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

On Thu, Oct 26, 2017 at 12:08 AM, Vlad Rozov <vr...@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 <vr...@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 <vr...@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 <vr...@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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

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

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.

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

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

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

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

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

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

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

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

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

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

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

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

Do I understand your suggestion correctly that Apex should allow 
contributions that introduce dependencies with critical security CVE or 
that breaks CI build for the sake of not making contributions difficult 
for contributors that do not have appetite to deal with CI build or 
check dependencies for CVE? If yes, what is your proposal how those 
issues should be addressed if addressed at all?

Should PR reviews be also skipped? I've heard complains from 
contributors/committers that PR reviews make it difficult to contribute.

Thank you,

Vlad

On 9/14/17 05:38, Priyanka Gugale wrote:
> I had one more point to add. During adding such checks we should think of
> all types of contributors. We don't want to make it very difficult to
> people to get in their PR, it will discourage people from putting any code
> changes. Ultimately we want to grow as a community where we would like
> people from different background and ideas to help us progress. All of them
> may not have good appetite for resolving such issues. So would like to have
> some process which is easy on contributors who are not well versed with
> such problems.
>
> Note: I don't want to say we don't do anything and let anyone put anything
> just to grow. I just want to say, let's not make it too difficult.
>
> -Priyanka
>
> On Wed, Sep 13, 2017 at 1:35 AM, Sanjay Pujare <sa...@datatorrent.com>
> 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 <vr...@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.
>>>>

Re: checking dependencies for known vulnerabilities

[Priyanka Gugale <pr...@apache.org>]

I had one more point to add. During adding such checks we should think of
all types of contributors. We don't want to make it very difficult to
people to get in their PR, it will discourage people from putting any code
changes. Ultimately we want to grow as a community where we would like
people from different background and ideas to help us progress. All of them
may not have good appetite for resolving such issues. So would like to have
some process which is easy on contributors who are not well versed with
such problems.

Note: I don't want to say we don't do anything and let anyone put anything
just to grow. I just want to say, let's not make it too difficult.

-Priyanka

On Wed, Sep 13, 2017 at 1:35 AM, Sanjay Pujare <sa...@datatorrent.com>
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 <vr...@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.
> >>
> >
>

Re: checking dependencies for known vulnerabilities

[Sanjay Pujare <sa...@datatorrent.com>]

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

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

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.
>
> On Mon, Sep 11, 2017 at 10:59 PM, Vlad Rozov <vr...@apache.org> wrote:
>
>> So, you are saying that those members are eager to see new features, new
>> functionalities and new code added to the project? Why they are not eager
>> to see a unit test being fixed or a dependency with a severe security risk
>> being removed? It is not that their original PR would be closed as a result
>> of a unit test fix. What prevents those community members to put time and
>> effort to fix CI build (unit test, dependency) that will directly benefit
>> the community but may not immediately benefit a vendor and its (paying)
>> customers?
>>
>> Thank you,
>>
>> Vlad
>>
>> On 9/11/17 22:08, Sanjay Pujare wrote:
>>
>>> Comments inline:
>>>
>>>
>>> On 9/10/17 23:40, Priyanka Gugale wrote:
>>>> It's good idea to check for vulnerabilities, but as Pramod said all
>>>>> softwares / libraries are going to have some or other vulnerability at
>>>>> any
>>>>> time. I will go with approach of "let's discuss this addition" and we
>>>>> should not affect PRs which are not adding any new dependencies (due to
>>>>> old
>>>>> vulnerabilities).
>>>>>
>>>>> While all software/libraries are subject to insecure code and
>>>> vulnerabilities, all software vendors whether open or close source
>>>> hopefully try to make code more secure rather than insecure. If there is
>>>> an
>>>> existing or newly introduced dependency with a critical security issue, I
>>>> don't see why Apex community wants to accept the high probability of
>>>> being
>>>> exposed to a security exploit. The only reasonable explanation for me is
>>>> that the community members do not care about overall project quality and
>>>> care only for tasks/PRs assigned to them by somebody else. I'll be glad
>>>> to
>>>> hear a different explanation for the proposal not to penalize PRs that do
>>>> not introduce new dependencies and are affected by a newly found
>>>> vulnerability in an existing dependency. Will not we all be penalized
>>>> later
>>>> if we don't fix it?
>>>>
>>>>
>>> I take exception to the insinuation that (some) community members "care
>>> only for tasks/PRs assigned to them by somebody else". It is quite
>>> possible
>>> or likely that these members are eager to see new features, new
>>> functionalities, or new code added to the project because they get excited
>>> by such things. You need to take into account the mindset of people who
>>> are
>>> submitting PRs to add a new functionality or fix a bug. The PR author's
>>> focus correctly is on addressing that particular JIRA and ensuring that
>>> JIRA gets resolved at the highest quality. To burden that PR author with
>>> unrelated considerations of build systems, vulnerability findings and such
>>> is not fair. Note that the project is (or should be) primarily driven by
>>> users (and customers in case of vendors shipping this code in products)
>>> who
>>> use these features and pay for these features. So we need to balance the
>>> long term concerns about "security issues" and quality with the immediate
>>> term concerns about adding features and functionalities.
>>>
>>>
>>>
>>> Also I also strongly feel, we need to be meticulous and think it through
>>>>> before introducing such checks for reasons discussed before.
>>>>>
>>>>> +1. Equally applies to a newly introduced functionality and bug fixes.
>>>> Totally agree. However when we discuss or "think through" any concerns
>>> they
>>> should apply to the issue at hand (i.e. the newly introduced functionality
>>> and bug fixes) and not external factors.
>>>
>>>
>>> -Priyanka
>>>>>
>>>>>

Re: checking dependencies for known vulnerabilities

[Sanjay Pujare <sa...@datatorrent.com>]

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.

On Mon, Sep 11, 2017 at 10:59 PM, Vlad Rozov <vr...@apache.org> wrote:

> So, you are saying that those members are eager to see new features, new
> functionalities and new code added to the project? Why they are not eager
> to see a unit test being fixed or a dependency with a severe security risk
> being removed? It is not that their original PR would be closed as a result
> of a unit test fix. What prevents those community members to put time and
> effort to fix CI build (unit test, dependency) that will directly benefit
> the community but may not immediately benefit a vendor and its (paying)
> customers?
>
> Thank you,
>
> Vlad
>
> On 9/11/17 22:08, Sanjay Pujare wrote:
>
>> Comments inline:
>>
>>
>> On 9/10/17 23:40, Priyanka Gugale wrote:
>>>
>>> It's good idea to check for vulnerabilities, but as Pramod said all
>>>> softwares / libraries are going to have some or other vulnerability at
>>>> any
>>>> time. I will go with approach of "let's discuss this addition" and we
>>>> should not affect PRs which are not adding any new dependencies (due to
>>>> old
>>>> vulnerabilities).
>>>>
>>>> While all software/libraries are subject to insecure code and
>>> vulnerabilities, all software vendors whether open or close source
>>> hopefully try to make code more secure rather than insecure. If there is
>>> an
>>> existing or newly introduced dependency with a critical security issue, I
>>> don't see why Apex community wants to accept the high probability of
>>> being
>>> exposed to a security exploit. The only reasonable explanation for me is
>>> that the community members do not care about overall project quality and
>>> care only for tasks/PRs assigned to them by somebody else. I'll be glad
>>> to
>>> hear a different explanation for the proposal not to penalize PRs that do
>>> not introduce new dependencies and are affected by a newly found
>>> vulnerability in an existing dependency. Will not we all be penalized
>>> later
>>> if we don't fix it?
>>>
>>>
>> I take exception to the insinuation that (some) community members "care
>> only for tasks/PRs assigned to them by somebody else". It is quite
>> possible
>> or likely that these members are eager to see new features, new
>> functionalities, or new code added to the project because they get excited
>> by such things. You need to take into account the mindset of people who
>> are
>> submitting PRs to add a new functionality or fix a bug. The PR author's
>> focus correctly is on addressing that particular JIRA and ensuring that
>> JIRA gets resolved at the highest quality. To burden that PR author with
>> unrelated considerations of build systems, vulnerability findings and such
>> is not fair. Note that the project is (or should be) primarily driven by
>> users (and customers in case of vendors shipping this code in products)
>> who
>> use these features and pay for these features. So we need to balance the
>> long term concerns about "security issues" and quality with the immediate
>> term concerns about adding features and functionalities.
>>
>>
>>
>> Also I also strongly feel, we need to be meticulous and think it through
>>>> before introducing such checks for reasons discussed before.
>>>>
>>>> +1. Equally applies to a newly introduced functionality and bug fixes.
>>>
>>> Totally agree. However when we discuss or "think through" any concerns
>> they
>> should apply to the issue at hand (i.e. the newly introduced functionality
>> and bug fixes) and not external factors.
>>
>>
>> -Priyanka
>>>>
>>>>
>>>>
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

So, you are saying that those members are eager to see new features, new 
functionalities and new code added to the project? Why they are not 
eager to see a unit test being fixed or a dependency with a severe 
security risk being removed? It is not that their original PR would be 
closed as a result of a unit test fix. What prevents those community 
members to put time and effort to fix CI build (unit test, dependency) 
that will directly benefit the community but may not immediately benefit 
a vendor and its (paying) customers?

Thank you,

Vlad

On 9/11/17 22:08, Sanjay Pujare wrote:
> Comments inline:
>
>
>> On 9/10/17 23:40, Priyanka Gugale wrote:
>>
>>> It's good idea to check for vulnerabilities, but as Pramod said all
>>> softwares / libraries are going to have some or other vulnerability at any
>>> time. I will go with approach of "let's discuss this addition" and we
>>> should not affect PRs which are not adding any new dependencies (due to
>>> old
>>> vulnerabilities).
>>>
>> While all software/libraries are subject to insecure code and
>> vulnerabilities, all software vendors whether open or close source
>> hopefully try to make code more secure rather than insecure. If there is an
>> existing or newly introduced dependency with a critical security issue, I
>> don't see why Apex community wants to accept the high probability of being
>> exposed to a security exploit. The only reasonable explanation for me is
>> that the community members do not care about overall project quality and
>> care only for tasks/PRs assigned to them by somebody else. I'll be glad to
>> hear a different explanation for the proposal not to penalize PRs that do
>> not introduce new dependencies and are affected by a newly found
>> vulnerability in an existing dependency. Will not we all be penalized later
>> if we don't fix it?
>>
>
> I take exception to the insinuation that (some) community members "care
> only for tasks/PRs assigned to them by somebody else". It is quite possible
> or likely that these members are eager to see new features, new
> functionalities, or new code added to the project because they get excited
> by such things. You need to take into account the mindset of people who are
> submitting PRs to add a new functionality or fix a bug. The PR author's
> focus correctly is on addressing that particular JIRA and ensuring that
> JIRA gets resolved at the highest quality. To burden that PR author with
> unrelated considerations of build systems, vulnerability findings and such
> is not fair. Note that the project is (or should be) primarily driven by
> users (and customers in case of vendors shipping this code in products) who
> use these features and pay for these features. So we need to balance the
> long term concerns about "security issues" and quality with the immediate
> term concerns about adding features and functionalities.
>
>
>
>>> Also I also strongly feel, we need to be meticulous and think it through
>>> before introducing such checks for reasons discussed before.
>>>
>> +1. Equally applies to a newly introduced functionality and bug fixes.
>>
> Totally agree. However when we discuss or "think through" any concerns they
> should apply to the issue at hand (i.e. the newly introduced functionality
> and bug fixes) and not external factors.
>
>
>>> -Priyanka
>>>
>>>

Re: checking dependencies for known vulnerabilities

[Sanjay Pujare <sa...@datatorrent.com>]

Comments inline:


> On 9/10/17 23:40, Priyanka Gugale wrote:
>
>> It's good idea to check for vulnerabilities, but as Pramod said all
>> softwares / libraries are going to have some or other vulnerability at any
>> time. I will go with approach of "let's discuss this addition" and we
>> should not affect PRs which are not adding any new dependencies (due to
>> old
>> vulnerabilities).
>>
> While all software/libraries are subject to insecure code and
> vulnerabilities, all software vendors whether open or close source
> hopefully try to make code more secure rather than insecure. If there is an
> existing or newly introduced dependency with a critical security issue, I
> don't see why Apex community wants to accept the high probability of being
> exposed to a security exploit. The only reasonable explanation for me is
> that the community members do not care about overall project quality and
> care only for tasks/PRs assigned to them by somebody else. I'll be glad to
> hear a different explanation for the proposal not to penalize PRs that do
> not introduce new dependencies and are affected by a newly found
> vulnerability in an existing dependency. Will not we all be penalized later
> if we don't fix it?
>


I take exception to the insinuation that (some) community members "care
only for tasks/PRs assigned to them by somebody else". It is quite possible
or likely that these members are eager to see new features, new
functionalities, or new code added to the project because they get excited
by such things. You need to take into account the mindset of people who are
submitting PRs to add a new functionality or fix a bug. The PR author's
focus correctly is on addressing that particular JIRA and ensuring that
JIRA gets resolved at the highest quality. To burden that PR author with
unrelated considerations of build systems, vulnerability findings and such
is not fair. Note that the project is (or should be) primarily driven by
users (and customers in case of vendors shipping this code in products) who
use these features and pay for these features. So we need to balance the
long term concerns about "security issues" and quality with the immediate
term concerns about adding features and functionalities.



>
>> Also I also strongly feel, we need to be meticulous and think it through
>> before introducing such checks for reasons discussed before.
>>
> +1. Equally applies to a newly introduced functionality and bug fixes.
>

Totally agree. However when we discuss or "think through" any concerns they
should apply to the issue at hand (i.e. the newly introduced functionality
and bug fixes) and not external factors.


>
>> -Priyanka
>>
>>
>>>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

Please see my comments inline.

Thank you,

Vlad

On 9/10/17 23:40, Priyanka Gugale wrote:
> It's good idea to check for vulnerabilities, but as Pramod said all
> softwares / libraries are going to have some or other vulnerability at any
> time. I will go with approach of "let's discuss this addition" and we
> should not affect PRs which are not adding any new dependencies (due to old
> vulnerabilities).
While all software/libraries are subject to insecure code and 
vulnerabilities, all software vendors whether open or close source 
hopefully try to make code more secure rather than insecure. If there is 
an existing or newly introduced dependency with a critical security 
issue, I don't see why Apex community wants to accept the high 
probability of being exposed to a security exploit. The only reasonable 
explanation for me is that the community members do not care about 
overall project quality and care only for tasks/PRs assigned to them by 
somebody else. I'll be glad to hear a different explanation for the 
proposal not to penalize PRs that do not introduce new dependencies and 
are affected by a newly found vulnerability in an existing dependency. 
Will not we all be penalized later if we don't fix it?
>
> Also I also strongly feel, we need to be meticulous and think it through
> before introducing such checks for reasons discussed before.
+1. Equally applies to a newly introduced functionality and bug fixes.
>
> -Priyanka
>
> On Sat, Sep 9, 2017 at 8:36 PM, Vlad Rozov <vr...@apache.org> wrote:
>
>> CVE are classified by severity levels or CVSS scores [1]. Any CVE that has
>> a score above 9.0 is considered to be critical. I am OK with "let's discuss
>> this addition" and consider probability of a CVE in a dependency leading to
>> a security exploit in Apex when the severity of the CVE is not critical.
>> For critical and possibly high severity level CVE, the approach should be
>> reversed - reject the additional dependency automatically and discuss if it
>> is OK to accept the dependency with the critical severity level. We may
>> discuss what is a cut off level and my recommendation is to use middle
>> point of the high severity (8.0).
>>
>> Without penalizing PRs that have nothing to do with a CI build failures
>> whether it is caused by a dependency check, change in a CI environment or
>> any other reason like unit test failure you promote the current community
>> no appetite for addressing non functional issues in Apex (actually another
>> example where the appetite is driven not by the community but by the
>> vendor). IMO, PRs must be automatically rejected when build fails in CI
>> (whether in Travis or Jenkins) and the burden must be on the community to
>> troubleshoot and resolve issues in the build or unit test (including
>> intermittent failures in the unit test). An attitude of the majority of the
>> current Apex community not to care for CI builds (and other non functional
>> issues like package names) unless an issue is introduced directly in their
>> PR at minimum should not be encouraged.
>>
>> I don't know if other Apache projects automatically reject dependencies
>> based on CVE. Every Apache community is independent and establishes it's
>> own process. What I know is that it would be better for Apex to avoid
>> mentions like [2].
>>
>> Thank you,
>>
>> Vlad
>>
>> [1] https://nvd.nist.gov/vuln-metrics/cvss
>> [2] http://thehackernews.com/2017/09/apache-struts-vulnerability.html
>>
>>
>> On 9/8/17 16:42, Sanjay Pujare wrote:
>>
>>> 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 <pr...@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 <vr...@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 <pramod@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.
>>>>>>
>>>>>>

Re: checking dependencies for known vulnerabilities

[Priyanka Gugale <pr...@apache.org>]

It's good idea to check for vulnerabilities, but as Pramod said all
softwares / libraries are going to have some or other vulnerability at any
time. I will go with approach of "let's discuss this addition" and we
should not affect PRs which are not adding any new dependencies (due to old
vulnerabilities).

Also I also strongly feel, we need to be meticulous and think it through
before introducing such checks for reasons discussed before.

-Priyanka

On Sat, Sep 9, 2017 at 8:36 PM, Vlad Rozov <vr...@apache.org> wrote:

> CVE are classified by severity levels or CVSS scores [1]. Any CVE that has
> a score above 9.0 is considered to be critical. I am OK with "let's discuss
> this addition" and consider probability of a CVE in a dependency leading to
> a security exploit in Apex when the severity of the CVE is not critical.
> For critical and possibly high severity level CVE, the approach should be
> reversed - reject the additional dependency automatically and discuss if it
> is OK to accept the dependency with the critical severity level. We may
> discuss what is a cut off level and my recommendation is to use middle
> point of the high severity (8.0).
>
> Without penalizing PRs that have nothing to do with a CI build failures
> whether it is caused by a dependency check, change in a CI environment or
> any other reason like unit test failure you promote the current community
> no appetite for addressing non functional issues in Apex (actually another
> example where the appetite is driven not by the community but by the
> vendor). IMO, PRs must be automatically rejected when build fails in CI
> (whether in Travis or Jenkins) and the burden must be on the community to
> troubleshoot and resolve issues in the build or unit test (including
> intermittent failures in the unit test). An attitude of the majority of the
> current Apex community not to care for CI builds (and other non functional
> issues like package names) unless an issue is introduced directly in their
> PR at minimum should not be encouraged.
>
> I don't know if other Apache projects automatically reject dependencies
> based on CVE. Every Apache community is independent and establishes it's
> own process. What I know is that it would be better for Apex to avoid
> mentions like [2].
>
> Thank you,
>
> Vlad
>
> [1] https://nvd.nist.gov/vuln-metrics/cvss
> [2] http://thehackernews.com/2017/09/apache-struts-vulnerability.html
>
>
> On 9/8/17 16:42, Sanjay Pujare wrote:
>
>> 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 <pr...@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 <vr...@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 <pramod@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.
>>>>>
>>>>>
>>>>>
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

CVE are classified by severity levels or CVSS scores [1]. Any CVE that 
has a score above 9.0 is considered to be critical. I am OK with "let's 
discuss this addition" and consider probability of a CVE in a dependency 
leading to a security exploit in Apex when the severity of the CVE is 
not critical. For critical and possibly high severity level CVE, the 
approach should be reversed - reject the additional dependency 
automatically and discuss if it is OK to accept the dependency with the 
critical severity level. We may discuss what is a cut off level and my 
recommendation is to use middle point of the high severity (8.0).

Without penalizing PRs that have nothing to do with a CI build failures 
whether it is caused by a dependency check, change in a CI environment 
or any other reason like unit test failure you promote the current 
community no appetite for addressing non functional issues in Apex 
(actually another example where the appetite is driven not by the 
community but by the vendor). IMO, PRs must be automatically rejected 
when build fails in CI (whether in Travis or Jenkins) and the burden 
must be on the community to troubleshoot and resolve issues in the build 
or unit test (including intermittent failures in the unit test). An 
attitude of the majority of the current Apex community not to care for 
CI builds (and other non functional issues like package names) unless an 
issue is introduced directly in their PR at minimum should not be 
encouraged.

I don't know if other Apache projects automatically reject dependencies 
based on CVE. Every Apache community is independent and establishes it's 
own process. What I know is that it would be better for Apex to avoid 
mentions like [2].

Thank you,

Vlad

[1] https://nvd.nist.gov/vuln-metrics/cvss
[2] http://thehackernews.com/2017/09/apache-struts-vulnerability.html

On 9/8/17 16:42, Sanjay Pujare wrote:
> 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 <pr...@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 <vr...@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 <pramod@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.
>>>>
>>>>

Re: checking dependencies for known vulnerabilities

[Sanjay Pujare <sa...@datatorrent.com>]

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 <pr...@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 <vr...@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 <pramod@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.
> >>
> >>
> >
>

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

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 <vr...@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 <pr...@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.
>>
>>
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

+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 <pr...@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.
>

Re: checking dependencies for known vulnerabilities

[Thomas Weise <th...@apache.org>]

On Fri, Sep 8, 2017 at 3:36 PM, Pramod Immaneni <pr...@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.

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

My response inline

On Fri, Sep 8, 2017 at 3:20 PM, Vlad Rozov <vr...@apache.org> wrote:

> The proposal is to automate detecting CVEs in existing or newly added
> dependencies based on an externally supported and updated database.
> Currently, nobody from the community monitors new additions to known CVEs
> and whether or not they affect dependencies used by Apex. By using the
> proposed maven plugin, it is possible to set a severity level of CVE when
> build would fail and gradually lower it over time. The CI build failure
> will be a strong indication for the community to address the issue and
> either reject newly introduced dependency or upgrade it to one where CVE is
> fixed (the same applies if a new CVE would be found in an existing
> dependency).
>
> I guess that it may be possible to suppress details of CVE and simply fail
> the build. Will that address the concern that the vulnerabilities cannot be
> reported in a public way?
>


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 tried implementing the plugin on my fork and the initial download size
> seems to be OK.
>
> Thank you,
>
> Vlad
>
>
> On 9/8/17 14:33, Pramod Immaneni wrote:
>
>> We will need to think about how much appetite the community has into
>> looking into these issues if and once they are reported. Last time when a
>> scan like this was run and several possible vulnerabilities in the
>> dependencies were reported, it took about a year to verify and address
>> them. Not because they were particularly hard to address but because there
>> were no volunteers. In fact, the majority of them if I remember correctly,
>> turned out to be non-issues for the software but somebody had to go
>> through
>> each one and make that determination. Also once these are reported they
>> become a high priority as they come into the radar of the security teams
>> in
>> apache and they need to be addressed in a timely manner and appropriate
>> reports filed. Second and more importantly, the vulnerabilities cannot be
>> reported in a public way which integrating with the open build systems
>> will
>> do. For these reasons I am -1 but I am willing to change my opinion if we
>> can find ways to mitigate both the concerns.
>>
>> Thanks
>>
>> On Fri, Sep 8, 2017 at 1:41 PM, Thomas Weise <th...@apache.org> wrote:
>>
>> +1 for implementing it. I'm not sure it will be suitable for CI build
>>> though due to initial download overhead?
>>>
>>>
>>> On Fri, Sep 8, 2017 at 1:33 PM, Vlad Rozov <v....@gmail.com> wrote:
>>>
>>> Any objections to implementing https://www.owasp.org/index.ph
>>>> p/OWASP_Dependency_Check maven plugin that will run on Travis/Jenkins
>>>> and
>>>> check for known vulnerabilities?
>>>>
>>>> Thank you,
>>>>
>>>> Vlad
>>>>
>>>>
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

The proposal is to automate detecting CVEs in existing or newly added 
dependencies based on an externally supported and updated database. 
Currently, nobody from the community monitors new additions to known 
CVEs and whether or not they affect dependencies used by Apex. By using 
the proposed maven plugin, it is possible to set a severity level of CVE 
when build would fail and gradually lower it over time. The CI build 
failure will be a strong indication for the community to address the 
issue and either reject newly introduced dependency or upgrade it to one 
where CVE is fixed (the same applies if a new CVE would be found in an 
existing dependency).

I guess that it may be possible to suppress details of CVE and simply 
fail the build. Will that address the concern that the vulnerabilities 
cannot be reported in a public way?

I tried implementing the plugin on my fork and the initial download size 
seems to be OK.

Thank you,

Vlad

On 9/8/17 14:33, Pramod Immaneni wrote:
> We will need to think about how much appetite the community has into
> looking into these issues if and once they are reported. Last time when a
> scan like this was run and several possible vulnerabilities in the
> dependencies were reported, it took about a year to verify and address
> them. Not because they were particularly hard to address but because there
> were no volunteers. In fact, the majority of them if I remember correctly,
> turned out to be non-issues for the software but somebody had to go through
> each one and make that determination. Also once these are reported they
> become a high priority as they come into the radar of the security teams in
> apache and they need to be addressed in a timely manner and appropriate
> reports filed. Second and more importantly, the vulnerabilities cannot be
> reported in a public way which integrating with the open build systems will
> do. For these reasons I am -1 but I am willing to change my opinion if we
> can find ways to mitigate both the concerns.
>
> Thanks
>
> On Fri, Sep 8, 2017 at 1:41 PM, Thomas Weise <th...@apache.org> wrote:
>
>> +1 for implementing it. I'm not sure it will be suitable for CI build
>> though due to initial download overhead?
>>
>>
>> On Fri, Sep 8, 2017 at 1:33 PM, Vlad Rozov <v....@gmail.com> wrote:
>>
>>> Any objections to implementing https://www.owasp.org/index.ph
>>> p/OWASP_Dependency_Check maven plugin that will run on Travis/Jenkins and
>>> check for known vulnerabilities?
>>>
>>> Thank you,
>>>
>>> Vlad
>>>

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

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 <th...@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 <pr...@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 <th...@apache.org> wrote:
> >
> > > On Fri, Sep 8, 2017 at 2:33 PM, Pramod Immaneni <
> pramod@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.
> > >
> >
>

Re: checking dependencies for known vulnerabilities

[Thomas Weise <th...@apache.org>]

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 <pr...@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 <th...@apache.org> wrote:
>
> > On Fri, Sep 8, 2017 at 2:33 PM, Pramod Immaneni <pr...@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.
> >
>

Re: checking dependencies for known vulnerabilities

[Vlad Rozov <vr...@apache.org>]

Amol,

Build may fail for multiple reasons, unless it outputs details of CVE 
that outlines how vulnerability can be exploited, the vulnerability is 
not exposed to the public.

I am +1 that it is better to know and monitor vulnerabilities than to 
proceed with a risk of introducing new dependencies with known 
vulnerabilities. All those tools that scan for vulnerabilities are 
publicly available and anyone can run them including those who will try 
to exploit the results of scans to maliciously gain access to data.

Thank you,

Vlad

On 9/8/17 15:41, Amol Kekre wrote:
> Vlad,
> Assuming you are in agreement that vulnerabilities should not be shown in
> public way; how would failing the build help. The reasons for failure will
> have be noted in public to be worked on. Anyway, IMO Apex may be better off
> exposing CVE as we are better off knowing these. But if folks want to
> details suppressed I am fine with it.
>
> The more important part is to amortize the cost of fixing CVE in current
> dependencies over time as pointed by you by lowering severity level
> gradually.
>
> Thks,
> Amol
>
>
>
> E:amol@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*
>
> www.datatorrent.com
>
>
> On Fri, Sep 8, 2017 at 3:21 PM, Pramod Immaneni <pr...@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 <th...@apache.org> wrote:
>>
>>> On Fri, Sep 8, 2017 at 2:33 PM, Pramod Immaneni <pr...@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.
>>>

Re: checking dependencies for known vulnerabilities

[Amol Kekre <am...@datatorrent.com>]

Vlad,
Assuming you are in agreement that vulnerabilities should not be shown in
public way; how would failing the build help. The reasons for failure will
have be noted in public to be worked on. Anyway, IMO Apex may be better off
exposing CVE as we are better off knowing these. But if folks want to
details suppressed I am fine with it.

The more important part is to amortize the cost of fixing CVE in current
dependencies over time as pointed by you by lowering severity level
gradually.

Thks,
Amol



E:amol@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*

www.datatorrent.com


On Fri, Sep 8, 2017 at 3:21 PM, Pramod Immaneni <pr...@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 <th...@apache.org> wrote:
>
> > On Fri, Sep 8, 2017 at 2:33 PM, Pramod Immaneni <pr...@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.
> >
>

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

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 <th...@apache.org> wrote:

> On Fri, Sep 8, 2017 at 2:33 PM, Pramod Immaneni <pr...@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.
>

Re: checking dependencies for known vulnerabilities

[Thomas Weise <th...@apache.org>]

On Fri, Sep 8, 2017 at 2:33 PM, Pramod Immaneni <pr...@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.

Re: checking dependencies for known vulnerabilities

[Pramod Immaneni <pr...@datatorrent.com>]

We will need to think about how much appetite the community has into
looking into these issues if and once they are reported. Last time when a
scan like this was run and several possible vulnerabilities in the
dependencies were reported, it took about a year to verify and address
them. Not because they were particularly hard to address but because there
were no volunteers. In fact, the majority of them if I remember correctly,
turned out to be non-issues for the software but somebody had to go through
each one and make that determination. Also once these are reported they
become a high priority as they come into the radar of the security teams in
apache and they need to be addressed in a timely manner and appropriate
reports filed. Second and more importantly, the vulnerabilities cannot be
reported in a public way which integrating with the open build systems will
do. For these reasons I am -1 but I am willing to change my opinion if we
can find ways to mitigate both the concerns.

Thanks

On Fri, Sep 8, 2017 at 1:41 PM, Thomas Weise <th...@apache.org> wrote:

> +1 for implementing it. I'm not sure it will be suitable for CI build
> though due to initial download overhead?
>
>
> On Fri, Sep 8, 2017 at 1:33 PM, Vlad Rozov <v....@gmail.com> wrote:
>
> > Any objections to implementing https://www.owasp.org/index.ph
> > p/OWASP_Dependency_Check maven plugin that will run on Travis/Jenkins and
> > check for known vulnerabilities?
> >
> > Thank you,
> >
> > Vlad
> >
>

Re: checking dependencies for known vulnerabilities

[Thomas Weise <th...@apache.org>]

+1 for implementing it. I'm not sure it will be suitable for CI build
though due to initial download overhead?


On Fri, Sep 8, 2017 at 1:33 PM, Vlad Rozov <v....@gmail.com> wrote:

> Any objections to implementing https://www.owasp.org/index.ph
> p/OWASP_Dependency_Check maven plugin that will run on Travis/Jenkins and
> check for known vulnerabilities?
>
> Thank you,
>
> Vlad
>