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

[Cheng Fang]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130619/f7f7f683/attachment.html