Whoa...Didn't realize I was that far behind on branch_1x. I _think_ it is now where it should be. I'll add the fuzzing module after the 1.24.1 release.
I'm finishing up the eval run now on the regression corpus. Results soonish... On Wed, Apr 8, 2020 at 7:33 AM Tim Allison <[email protected]> wrote: > Didn't I "fix" this in master: > https://github.com/apache/tika/commit/f0ae10b072d7d486fed227088d82a3fd4a8d4f1f > ? > > The build should work now. I updated the release process documentation to > turn back on "fail the build on vulnerability" right before release. > > I agree that we need to continue to update our dependencies, and I need to > cherry-pick a bunch of commits to branch_1x, which I'll do today. > > But, the build should work on master... let me know if it doesn't. > > Cheers, > > Tim > > On Wed, Apr 8, 2020 at 7:24 AM Eric Pugh <[email protected]> > wrote: > >> If you bump cxf one version, then the complaints stop ;-) >> >> >> https://github.com/apache/tika/pull/316/commits/ee93e6d3d91bdfc40f838556c13698ea5c78e936 >> >> >> >> > On Apr 8, 2020, at 5:35 AM, Sergey Beryozkin <[email protected]> >> wrote: >> > >> > Hi Lewis >> > >> > Getting one of the latest releases should be fine; while I've been out >> of >> > touch with CXF recently, I can ask around for some version advice as the >> > guys deal with the security vulnerabilities seriously there, if >> addressing >> > this issue proves problematic >> > Cheers, Sergey >> > >> > On Tue, Apr 7, 2020 at 10:44 PM Lewis John McGibbney < >> [email protected]> >> > wrote: >> > >> >> I suspected this was the case folks :) >> >> I actually really like this idea. >> >> I'll take the action item to address this seeing as I pulled it up... >> >> seeing as I am also working on tika-server right now I'll also take the >> >> action item to address the vulnerable CXF deps. >> >> Thanks, >> >> Lewis >> >> >> >> On 2020/04/06 16:19:16, Tim Allison <[email protected]> wrote: >> >>>> We shouldn't have any at release time, but they will obviously creep >> in >> >>> between releases >> >>> >> >>> Except the time, where I did the release and was trying to build it >> for >> >>> updating the site, and this had already kicked in. :( >> >>> >> >>> Y, we can turn this to warn, as long as we run it with fail as part of >> >> the >> >>> release process. >> >>> >> >>> On Mon, Apr 6, 2020 at 9:59 AM Nick Burch <[email protected]> >> wrote: >> >>> >> >>>> On Mon, 6 Apr 2020, Eric Pugh wrote: >> >>>>> Maybe this needs better documentation, however this is a “works as >> >>>>> designed” feature! >> >>>>> >> >>>>> To avoid the build failing, run mvn package -Dossindex.fail=false >> >>>> >> >>>> Should we maybe have this set to false by default, and only enabled >> >>>> on release builds? >> >>>> >> >>>> (We shouldn't have any at release time, but they will obviously creep >> >> in >> >>>> between releases) >> >>>> >> >>>> Nick >> >>> >> >> >> >> _______________________ >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com < >> http://www.opensourceconnections.com/> | My Free/Busy < >> http://tinyurl.com/eric-cal> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >> >> This e-mail and all contents, including attachments, is considered to be >> Company Confidential unless explicitly stated otherwise, regardless of >> whether attachments are marked as such. >> >>
