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 <vro...@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 <pra...@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 <vro...@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 <pra...@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.
