On 05/11/2018 19:48, Christopher Schultz wrote: > On 11/5/18 13:05, Rainer Jung wrote: >> Am 05.11.2018 um 18:44 schrieb Christopher Schultz:
<snip/> >>> What am I missing, here? > >> Try setting test.openssl.path in build.properties to the full path >> to the openssl binary (.../bin/openssl). > >> See r1614560 and r1614587. > > Aha! That was it! > > I was confused because I was thinking that the version was being > properly-detected by Tomcat. But the tests were using the "openssl > ciphers" command to pull the lists of ciphers instead of doing it > using JNI. > > Would it be worth it to use JNI to pull-back the list of supported > ciphers instead of running an external command? The purpose of the tests is to ensure that the Tomcat code that replicates OpenSSL's cipher selection behaves the same way as the latest OpenSSL code. I don't see that it matters whether we determine the OpenSSL behaviour via an external command or JNI. The upside is more consistent tests and one less build parameter to configure. The downside is APR/native becomes required for those tests. Running those tests for all three connectors is fairly pointless so only running them with APR might be an upside. I haven't checked to see if the API we'd need to use is accessible via the current JNI API or whether we'd need to extend it. Is it worth it? For me this in the the category of it looks to be a worthwhile itch to scratch if someone wants to scratch it. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
