On 19 October 2017 15:11:19 BST, Brian Clozel <bclo...@pivotal.io> wrote: >Hi, > >More and more servers are choosing to make available one or more >solutions >to use TLS native stacks by shipping them as JARs: > >* Netty has quite a few options there >http://netty.io/wiki/forked-tomcat-native.html >* Jetty is now shipping a conscrypt support as well >https://webtide.com/conscrypting-native-ssl-for-jetty/ >
How does shipping a native library in a JAR work? What makes it simpler than building from source? (Past experience of providing binaries for OS other than Windows is that the number of different builds rapidly multiplies - hence source only at the moment.) >I know there are other solutions for that, like changing the boot >classpath >or installing native libraries directly on the host operating system. >But >those solutions aren't always super easy to achieve in cloud >environments; >there are also questions on this mailing list around >tomcat+tcnative+openssl versions compatibility. > >Would the Tomcat community consider shipping JARs (with classifier and >uber >JARs) containing the required native libraries (libtcnative + openssl + >apr)? In principle no reason why not but more detail on the requirements is needed. >Bonus question: would you consider supporting boringssl or libressl? Libressl is supported as of 1.2.13 apart from some features where we need functionality not available in libressl (I forget what those features were but I don't think they were significant) Boringssl should be doable as well but I don't think anyone has tried it yet. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
