Re: On tomcat FTBFS.
I'm investigating tomcat8's FTBFS and I confirm Abhijith's findings in a
- test catalina/connector/TestSendFile.java fails with nio2 connector
but is not reliable and will report success ~1 out of 10 even with lots
of exceptions; catalina.log will report header parsing error and return 400
- it passes reliably without CVE-2017-5647.patch
- the test certificate did expire on 2019-02-27 but changing the date to
2019-01-01 and rebuilding does not impact these results
(incidentally the test certs seems to depend on an external CA
ca-test.tomcat.apache.org, fixing the certs will require switching to
the new-style local CA in tomcat8 - if fixing the certs is needed)
As you fixed CVE-2017-5647 as well as generated the last jessie upload,
I would be interested in your take on this :)
TestSendFile only got trivial changes, so I guess I'll look for a fix in
later changes affecting files modified by CVE-2017-5647.
Still, I'm surprised updates were built given this situation - did
everybody got lucky with the flacky test or did I miss something?
On 27/07/2019 20:30, Abhijith PA wrote:
> I don't think the link you gave on commit [fe932dd39d] is the reason for
> FTBFS. I tried building on a VM that matches the certificate date and it
> was successful. I also tried disabling all ssl related tests and was fine.
> While doing these all I found TestSendFile test is the culprit. In
> CVE-2017-5647 security patch a good amount of changes is applied for
> SendFile*.java and *Nio2*.java. These are mostly about conditions on how
> long the socket of sendfile keep active and to take away from it. But I
> couldn't see any those change in its test file. Please take a look on
> the attached patch. :)