apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pramod Immaneni <pra...@datatorrent.com>
Subject Re: checking dependencies for known vulnerabilities
Date Thu, 02 Nov 2017 23:50:52 GMT
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 <thw@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 <ananthg.apex@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 <ananthg.apex@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 <thw@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.
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>
> > > >>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message