Yeah, so I pushed updated to commons and tika yesterday to the master branch, I also added the plugin to the build chain but stuck it under the cve-check profile because it does slow the build down a bit whilst it crawls the web.
Tom On Tue, Sep 12, 2017 at 1:42 PM, lewis john mcgibbney <lewi...@apache.org> wrote: > Ack > I think starting upgrades with the four modules you've highlighted would be > a big move in the right direction. > Is it possible to integrate this tool as part of the build and have reports > generated automatically? This way we would know from time to time when > newer more stable versions of a dependency are available for upgrade... > > On Tue, Sep 12, 2017 at 12:38 AM Tom Barber <t...@spicule.co.uk> wrote: > > > Thanks for the feedback chaps. > > > > Lewis, the report is broken down into CVEs and the tools likelyhood of > the > > stuff it detected being accurate. > > > > I think some stuff is pretty obvious, take for example Apache Commons > > Collections, that had a Java Serialization bug that allowed for remote > code > > execution in 3.2.1 but is fixed in 3.2.2 ( > > https://commons.apache.org/proper/commons-collections/ > security-reports.html > > ) > > and the issue has been in the wild since 2015. We can tackle simple stuff > > like this just by shipping an updated version, I assume 3.2.1 to 3.2.2 > > shouldn't prove too arduous and update. > > > > Others like CVE-2016-6809 need a bit more digging as their severity is > high > > but confidence low, but turns out Tika did have a matlab exploit that > > seemingly got addressed in 1.14. > > > > As I said, I'm not looking to run out there and ship a big release to > fix > > all of these, but its worth addressing as we move forward. > > > > Tom > > > > On Mon, Sep 11, 2017 at 5:31 PM, Sean Kelly <ke...@apache.org> wrote: > > > > > Huh. That's a nifty tool. > > > > > > A little frightening. > > > > > > --k > > > > > >> Tom Barber <mailto:t...@spicule.co.uk> > > >> 2017-09-9 at 8.03 a > > >> > > >> Hi folks > > >> > > >> This isn't supposed to be an alarmist email, but quite enlightening > all > > >> the > > >> same. > > >> > > >> I saw a link to a plugin on the Drill mailing list called Dependency > > Check > > >> Report so I wired it into my OODT repo amongst others to see what was > > >> flagged up since the Struts fallout. > > >> > > >> Anyway, of course its unlikely but not out of the question to run OODT > > >> fronting on to the interwebs so I think this is decent food for > thought > > as > > >> to why its useful to keep dependencies up to date as much as possible. > > >> > > >> Here's a selection of the output: > > >> > > >> https://www.dropbox.com/s/2ida8dk54yleedo/curator-webapp.html?dl=0 > > >> https://www.dropbox.com/s/wgt1facgjhqiqkq/fmbrowser.html?dl=0 > > >> https://www.dropbox.com/s/o8kqcaktplzjy4y/metadata.html?dl=0 > > >> https://www.dropbox.com/s/cli4pj4jc564f16/pge.html?dl=0 > > >> > > >> Of course there is a bunch of repetition in there and plenty that > aren't > > >> over the top severe, some may also be false positives, but as we work > > >> through to OODT 2.0 with the new stuff and chopping out the old stuff, > > >> reducing these as much as possible I would posture. > > >> > > >> Tom > > >> > > >> > > > -- > http://home.apache.org/~lewismc/ > @hectorMcSpector > http://www.linkedin.com/in/lmcgibbney >
