[wildfly-dev] Implementing enforce-victims-rule in wildfly builds

[David Jorm]

Thanks for testing, Cheng. You should be able to limit the plugin to only check for new vulnerabilities in the DB once per day by setting:

<updates>daily</updates>

As a child element of:

<rule implementation="com.redhat.victims.VictimsRule">

Checking for updates once per maven run is not currently supported. This is because the plugin is re-initialized by maven for each subproject in the maven build. So there is no easy way to do this at the moment - hopefully the daily update frequency is sufficient.

With this setting in place, do you think we're in a position to try committing the plugin configuration to a dedicated maven profile in the root pom.xml, and setting up a jenkins job to run builds using that profile?

Thanks
David

> Thanks David for the update. I tried rule version 1.3.1 on wildfly by adding
> the configuration snippet to root pom.xml. After removing ~/.victims, and
> doing ./build.sh clean install, it took about 15 minutes 34 seconds to
> complete.
> 
> The message "Checking for new vulnerabilities..." appeared 122 times. The
> first time it tries to initialize the victim database, it took maybe 10-15
> seconds, and the rest 121 times took 3-4 seconds each. So roughly the time
> spent on checking for vulnerabilities updates are about 5-6 minutes.
> 
> Running build.sh clean installl a second time with the plugin took 9:52.217s.
> 
> It would be nice if it only checks for vulnerabilities update once per mvn
> run, or once during a certain time period (say 8 hours).
> 
> Cheng
> 
> On 6/12/13 9:24 PM, David Jorm wrote:
> 
> 
> 
> Hi All
> 
> Just following up on this. Has anyone had a chance to test a build of WildFly
> with enforce-victims-rule 1.3? From my perspective I think it should be
> ready to use.
> 
> Thanks
> David
> 
> 
> 
> This bug is now fixed in enforce-victims-rule 1.3, which was released to
> maven central today. This release also includes a range of performance
> improvements, including caching, which significantly improves performance
> after the first build of a given project. We have tested it with WildFly 8
> on a system where build time without the plugin was 10 minutes. With the
> plugin, the first build took 19 minutes, and all subsequent builds took 11
> minutes.
> 
> Can you please rm -rf ~/.victims/ then update your POM to reference
> enforce-victims-rule 1.3 and try again?
> 
> Thanks
> David
> 
> 
> 
> Thanks for reporting this issue. We suspect it is actually a bug in the
> victims library, as false negatives or artifacts that do not exist in the
> DB
> should simply pass inspection with no warning or failure. We've fixed the
> suspected bug and we're currently working on an updated release, I will
> respond to the list once that is complete so you can test.
> 
> Thanks
> David
> 
> 
> 
> Yes, the build failed.  This plugin can be configured to WARNING level
> in the pom, but we then we won't catch the real problems.  In the test
> run, I just copied the pom snippet from
> https://github.com/victims/victims-enforcer In my case, the failed test
> project is
> https://github.com/jberet/jsr352/blob/master/test-apps/postConstruct/pom.xml
> ,
> which has just 1 direct dependency: an internal peer sub-module, which I
> guess is not known to the scanner database. Probably that's why it
> failed?  But other similarlly-structured sub-modules passed (e.g.,
> https://github.com/jberet/jsr352/blob/master/test-apps/propertyInjection/pom.xml
> )
> 
> Cheng
> 
> On 5/29/13 9:55 AM, Brian Stansberry wrote:
> 
> 
> 
> On 5/28/13 9:56 PM, Cheng Fang wrote:
> 
> 
> 
> The possible false negatives (as David mentioned in his original
> email)
> can also complicate otherwise successful builds.  The following error
> message might have been caused by gaps in the database, though it's
> not
> clear which dependency it is complaining about.
> 
> [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message:
> Could not determine vulnerabilities for hash:
> 8edd1a0bf70467791ec883b7452c21333e829ab714c83090f8328d8205f159f2669772dd66db01af60debd40402e994be7b08527e8f90211425567b52e6b9472
> Does that fail the build, or is the problem limited to noise in the
> build log?
> _______________________________________________
> wildfly-dev mailing list wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>