On 24/04/2020 00:45, Michael Osipov wrote: > Folks, > > I run test from Tomcat master and libtcnative master on FreeBSD, RHEL 7 > and HP-UX 11.31 on a regular basis and noticed that the OpenSSL 1.0.2 > packages provided by Red Hat and HPE are modified which make several > tests fail. See an excerpt here [1]. > To verify this I have compiled OpenSSL from OpenSSL_1_0_2-stable on > FreeBSD w/o any modification and all tests pass, so other must have > modified OpenSSL. > > What is our position in terms of support/testing for modified OpenSSL > packages from OS vendors? Should we add a big fat warning somewhere? Add > this to tcnative README that we test/recommend upstream only?
The good news is that the tests that are failing are the ones I would expect to fail. When we added the code that lets us use OpenSSL syntax to define ciphers for JSSE (and JSSE syntax to define ciphers for OpenSSL) we added a these tests to ensure that we correctly tracked things like "ALL", "DEFAULT" as well as "ECDHE" etc. These are a moving target as support for new ciphers is added and ciphers viewed as less secure are removed. Our unit tests aim to work with the current version of all publicly supported OpenSSL branches. Currently, master (3.0.x) and 1.1.1. I expect the vendor supported 1.0.2 packages are close to current 1.1.1 but I wouldn't be surprised to see some minor differences. I think we have several options: - document the expectation more clearly so folks can more easily assess these failures - support using the vendor supported versions with the unit tests - provide a configuration option to skip these tests - detect vendor supplied OpenSSL and automatically skip the tests There are probably a few options I've missed. I will add at this point that debugging a failure and figuring out the right fix hasn't always easy. I'm currently wondering if some sort of combination of the above might work. Detect vendor variations, handle them where we can recognise them and skip them where we don't. I think this needs some further thought. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
