Very good. Are we opening tickets for all of the upgrades or... On Wed, Sep 13, 2017 at 3:44 AM Tom Barber <t...@spicule.co.uk> wrote:
> 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 > > > -- http://home.apache.org/~lewismc/ @hectorMcSpector http://www.linkedin.com/in/lmcgibbney
