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 <vro...@apache.org> wrote:
There is a way to add an exception, but it needs to be discussed on a case
by case basis. Note that CVEs are not published until a fix is available.
For severity 8 CVEs I expect patches to become available for the reported
version unless it is an obsolete version in which case, the upgrade to a
supported version is already overdue.
I think we should retain the ability to make that choice of what and when
to upgrade rather than hard enforce it. Like I mentioned the CVE may not
apply to us (it has happened before), even though it may be beneficial
upgrade generally when its not applicable, there may not be the bandwidth
in community to do the necessary changes to upgrade to a newer version
especially if those dependencies don't follow semver (has happened before
as well, remember effort with ning). My caution comes from experiencing
this situation before.
I don't see how reporting helps. If a build succeeds, I don't expect
anyone to look into the report, it is only when CI build fails, committers
and reviewers look into the details.
We can add a mandatory step during release that we need to assess CVEs
matching this criteria before proceeding with the release. This could end
up requiring upgrade of some dependencies and in other cases it may not be
needed. This assessment can also happen more often in adhoc fashion offline
before release based upon interest from community. I am also open to making
it mandatory with every PR, in future, like you are suggesting, if we see
sufficient uptake in community on these issues. From experience this is not
there currently and hence I don't want to do this now.
IMO, it does not matter how CVE is introduced. It may be a new dependency
with an existing CVE or it can be a new CVE for an existing dependency. In
both cases, dependency with the CVE needs to be fixed.
In one case the PR is not directly responsible for the issue and hence we
should avoid penalizing them or block them.
Thank you,
Vlad
On 10/25/17 11:58, Pramod Immaneni wrote:
Thanks that sounds mostly fine except what happens if there is a cve
matching that severity in a dependency but it doesnt affect us because
let's say we don't exercise that part of functionality *and* there isn't a
fix available or there is a fix but the upgrade requires significant
effort
(for example if we need to move to a new major version of the dependency
or
something like that). Is there a way to add an exception like we did for
checkstyle in the interim. How about reporting instead of failing the
builds. One of the steps in release process could be to investigate these
reports before proceeding with the release. If a PR introduces new cves by
virtue of adding a new dependency or changing an existing version, that
would be of interest and can be subject to failure. Is there a way to
distinguish that?
On Wed, Oct 25, 2017 at 8:52 AM Vlad Rozov <vro...@apache.org> wrote:
A CVE (should there be a vulnerability in existing or a newly introduced
dependency) will not be exposed during the CI build, but the build will
fail if the CVE has severity 8 or above. To get the details, it will be
necessary to run dependency check manually.
Thank you,
Vlad
On 10/24/17 16:27, Pramod Immaneni wrote:
There was a lot of discussion on this but looks like there was no final
agreement. Can you summarize what your PR does? Are we disclosing the
actual vulnerabilities as part of the automated build for every PR? That
would be a no-no for me. If it is something that requires manual steps,
for
example as part of a release build, that would be fine.
On Mon, Oct 23, 2017 at 1:16 PM, Vlad Rozov <vro...@apache.org> wrote:
Please see https://github.com/apache/apex-core/pull/585 and
APEXCORE-790.
Thank you,
Vlad
On 9/14/17 09:35, Vlad Rozov wrote:
Do you expect anything else from the community to recognize a
contribution other than committing it to the code line? Once there is
a
steady flow of quality contributions, the community/PMC will recognize
a
contributor by making that contributor a committer.
Thank you,
Vlad
On 9/12/17 13:05, Sanjay Pujare wrote:
For a vendor too, quality ought to be as important as security so I
don't
think we disagree on the cost benefit analysis. But I get your drift.
By "creative incentive" I didn't imply any material incentive
(although a
gift card would be nice :-)) but more along the lines of what a
community
can do to recognize such contribution.
Sanjay
On Tue, Sep 12, 2017 at 8:10 AM, Vlad Rozov <vro...@apache.org>
wrote:
I guess we have a different view on the benefit and cost definition.
For
me the benefit of fixing CI build, flaky unit test, severe security
issue
is huge for the community and is possibly small (except for a
security
issues) for a vendor.
By "creative" I hope you don't mean that other community members,
users
and customers send a contributor a gift cards to compensate for the
cost
:). For me PR that is blocked on a failed CI build is sufficiently
incentive for a contributor to look into why it fails and fixing it.
Thank you,
Vlad
On 9/11/17 23:58, Sanjay Pujare wrote:
I don't want to speak for others and I don't want to generalize. But
an
obvious answer could be "cost-benefit analysis".
In any case we should come up with a creative way to "incentivize"
members
to do these tasks.
