Is there a property to fail the build in case we find a vulnerable component?

@rafaelweingartner i don't want to think about that yet.. :(

because it might start breaking our builds and then we will have to fix it?
I wonder if this report will be something like the Coverity report that we had or even the sonar report that we had (do we still have them?) that people just ignore.

yes, they are ignorable, just a help but afcourse we can set them to block the build. You don't want to do that in the present state though

@DaanHoogland Can't you try to address the dependencies CVE too in this PR by updating them to the fixed ones? Then you'll be able to put flag the build as failed if any new CVE happens.
Just to note that a same build can then start to fail even though it did not in the past!

No @marcaurele, we need to go there I agree, but it is a bridge to far now

Let me add to that:
I think a PR should be stopped on a dependency CVE but a build should not fail. Builds must be reproducible even (or especially) when there are vulnerabilities in it.

So, what we need is a jenkins job to report the "sanity/quality" of a PR's dependencies as a status in the Github's PR page.

I think it would be best to have a apache jenkins job that reports to sec@
that doesn't exclude your idea btw, @rafaelweingartner

@blueorangutan package

@borisstoyanov a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1705

@blueorangutan test

@borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

Trillian test result (tid-2251)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 30372 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2446-t2251-kvm-centos7.zip
Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
Smoke tests completed. 66 look OK, 1 have error(s)
Only failed tests results shown below:

@marcaurele are you -1 on this chance as is?

yes of course @rafaelweingartner , let's squash on merge. I am kind of worried that three of the travis jobs time out. not sure if that is related.

I restarted travis job, if it turns out green I will proceed and merge this one

@DaanHoogland I pulled your branch and I tried to compile it here, but I got the following error:

Failed to execute goal org.owasp:dependency-check-maven:3.1.1:check (default) on project cloudstack: A type incompatibility occured while executing org.owasp:dependency-check-maven:3.1.1:check: org.sonatype.aether.util.DefaultRepositorySystemSession cannot be cast to org.eclipse.aether.RepositorySystemSession

This is the command I am using:
mvn clean install -P developer -Dsimulator -Dmaven.test.skip=false

Never mind, I found the problem. It is caused due to maven version [1]. Now I see the need for PR #2343.
@khos2ow I think we need to revisit and move that PR forward.

Travis is already using Maven 3.5, so the problem is not due to maven version there. I believe the problem is due to "dependency-check-maven" first run, when it downloads and processes CVEs to populate its local database.

@DaanHoogland we need to add travis_wait <someValueBiggerThan10> in front of install: ./tools/travis/install.sh directive. Something like install: travis_wait 30 ./tools/travis/install.sh

[1] http://maven.40175.n5.nabble.com/Re-Build-failed-in-Jenkins-maven-plugins-ITs-m3-972-td5755380.html

@rafaelweingartner I'm still in favor of proceeding with that PR, because it will make build jobs immutable and reproducible as well.

@DaanHoogland can you check and fix Travis failures?

@DaanHoogland is this good to go? let me re-kick travis.

@rafaelweingartner @GabrielBrascher how are we doing with this PR? /CC @DaanHoogland