Re: On tomcat FTBFS.
Hi,
On Thu, Aug 08, 2019 at 02:15:52PM +0200, Markus Koschany wrote:
> Am 08.08.19 um 00:50 schrieb Sylvain Beucler:
> > So I reworked CVE-2017-5647, which involved 5 new commits related to
> > non-blocking I/O (NIO2 and COMET).
> > Stable build.
> >
> > Then I got upstream to renew their new certs that were expiring tomorrow (!)
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=63648
> > and had to fix-up the SSL client tests accordingly (new client DN).
> >
> > At last we have a working package that passes the testsuite.
> > How would you smoke-test it?
> > https://www.beuc.net/tmp/debian-lts/tomcat8/
>
> You can safely ignore all SSL test failures. I suggest you compare the
> output of the current Tomcat release with the output after you have
> fixed the newly reported CVE. If you discover new test failures
> unrelated to the current ones, then it deserves further investigation.
> After that you can simply run DEB_BUILD_OPTIONS=nocheck to avoid the
> FTBFS.
There's no more FTBFS, but I now understand how the previous uploads
"passed" the test suite :)
> Another option is to upgrade to the latest stable release in case
> the changes are too complex and a backport is becoming more and more
> time consuming. Please note that I have fixed CVE-2017-5647 2,5 years
> ago as a member of the Java team. I don't believe that the new commits
> are directly related to CVE-2017-5647. This appears to be a bug that was
> always present and was only fixed after Jessie became stable.
Well, following the advice above, I tested with and without the
CVE-2017-5647 patch, and observed a regression in TestSendFile, which
I fixed with the new commits.
Incidentally the failures Roberto experienced at
https://lists.debian.org/debian-lts/2018/07/msg00056.html were likely
caused by building with no network, which seems to break a few tests
requiring a fully-functional local network (I just experienced the
same tests failing within pbuilder).
Cheers!
Sylvain
Reply to: