On 24/02/2015 10:22, Rainer Jung wrote: > Am 24.02.2015 um 10:01 schrieb Mark Thomas: > >> On a related topic the Gump OpenSSL tests are still failing. They pass >> when run directly from the command line on vmgump.a.o. I can't come up >> with a better idea than adding some debugging to the tests. > > I installed OpenSSL master (current snapshot) locally and ran the > TestOpenSSLCipherConfigurationParser test against our trunk.I get > failures as well although I can confirm, that the correct OpenSSL > version 1.1.0-dev was used.
OK. I'll take another look at my local tests on vmgump. I guess I was doing something wrong. > Looking at the simplest failure example "SSLv2": OpenSSL 1.1.0 no longer > supports SSLv2, so "openssl ciphers -v SSLv2" returns and empty result > and that is what the test expects. OTOH in > TestOpenSSLCipherConfigurationParser there are about 6 ciphers which are > defined for SSLv2 and those show up in the failed tests (plus some of > their aliases). > > Not sure how to handle OpenSSL version compatibility in the tests and in > the Tomcat runtime code. Which version of OpenSSl is > java/org/apache/tomcat/util/net/jsse/openssl/ supposed to reflect? Any > specific version, or any cipher existing in some OpenSSL version? Any cipher in any (supported) OpenSSL version. > That code I think does not actually use OpenSSL and is only a translation > mechanism from OpenSSL syntax to JSSE syntax, correct? Correct. > The test OTOH actually use OpenSSL and compare results, so would never > be compatible with a extended cipher list. Maybe for testing we need to > mark the ciphers in the list, that actually exist in the OpenSSL version > that's supposed to be used during the tests? That is sort of what is meant to be happening but the list is hard-coded to a specific OpenSSL version. Different versions are used for different Tomcat branches. > I don't have a convincing idea... The main purpose of the tests is to catch when new ciphers are supported by OpenSSL or the JRE so we can ensure they are correctly mapped. I'm open to any idea that achieves this aim and improves what we have at the moment. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
