On Tue, Nov 23, 2021 at 11:18 AM Rémy Maucherat <[email protected]> wrote:
> On Tue, Nov 23, 2021 at 9:33 AM Martin Grigorov <[email protected]> > wrote: > > > > Hi Remy, > > > > On Tue, Nov 23, 2021 at 9:49 AM Rémy Maucherat <[email protected]> wrote: > > > > > On Mon, Nov 22, 2021 at 10:55 PM Christopher Schultz > > > <[email protected]> wrote: > > > > > > > > Rémy, > > > > > > > > On 11/22/21 02:00, Rémy Maucherat wrote: > > > > > I am done with the initial version of the OpenSSL with Panama > module. > > > > > > > > Fantastic. > > > > > > > > > It could be time for more testing and build releases (obviously > > > > > targeting only Java 17). It should also be easy to add new > features as > > > > > needed since the full OpenSSL API is available and there's no hard > to > > > > > update subcomponent to release first. I only focused on replicating > > > > > the functionality that was in tomcat-native. > > > > > > > > > > What would be the best way to proceed ? > > > > > > > > What does it take to run Tomcat's unit-test suite with Panama > enabled, > > > > instead of e.g. tcnative? > > > > > > This needs some modifications to the tests, just as there's code to > > > run JSSE (or tomcat-native). > > > parameterSets.add(new Object[] { > > > "JSSE", Boolean.FALSE, > > > "org.apache.tomcat.util.net.jsse.JSSEImplementation"}); > > > would be: > > > "OpenSSL-Panama", Boolean.FALSE, > > > "org.apache.tomcat.util.net.openssl.panama.OpenSSLImplementation"}); > > > I did that in all relevant tests for testing (and removed the two > > > others to get faster runs). This now needs extra code to make it run > > > only on Java 17. > > > > > > > build.xml needs some changes too (and they need to be optional, as the > > > arguments only work on Java 17): > > > > > > diff --git a/build.xml b/build.xml > > > index fbba5d7..4046afe 100644 > > > --- a/build.xml > > > +++ b/build.xml > > > @@ -238,6 +238,7 @@ > > > <pathelement location="${derby.jar}"/> > > > <pathelement location="${derby-shared.jar}"/> > > > <pathelement location="${derby-tools.jar}"/> > > > + <pathelement location="output/build/lib/tomcat-openssl-0.1.jar"/> > > > <path refid="compile.classpath" /> > > > <path refid="tomcat.classpath" /> > > > </path> > > > @@ -1938,6 +1938,9 @@ > > > <jvmarg > > > value="--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED"/> > > > <jvmarg > value="--add-opens=java.base/java.util=ALL-UNNAMED"/> > > > <jvmarg > > > value="--add-opens=java.base/java.util.concurrent=ALL-UNNAMED"/> > > > + <jvmarg value="--enable-native-access=ALL-UNNAMED"/> > > > + <jvmarg value="--add-modules"/> > > > + <jvmarg value="jdk.incubator.foreign"/> > > > > > > <classpath refid="tomcat.test.classpath" /> > > > > > > I'm not sure how to make the tests fail nice if OpenSSL isn't there. > > > The first step is to release a build (like for the migration tool) > > > since otherwise this cannot really be done properly. > > > > > > > I could test it on Linux ARM64! > > Ok ! > > > But to make it easier for me and anyone else: can we control the JVM args > > in build.xml and the JVM properties in the tests via build.properties ? > > I.e. if I set some new property in build.properties then all of the above > > to be done for me wthout manually patching around. > > I cannot do anything to make the testsuite "ready to run" without a > build out first. The current mechanism for selecting > sslImplementationName does not use system properties, so I have to > change all the tests. > Yes, the respective tests have to be updated. I could do it too in the coming weeks. > > Rémy > > > Martin > > > > > > > > > > > It might help to post an "invitation to try something out" and see if > > > > anyone gets failures you didn't get during your work. > > > > > > > > > I also updated the panama-foreign version of it since it is now > > > > > stable-with-workaround, at: > > > > > https://github.com/rmaucher/openssl-panama-foreign . It will > > > > > eventually require whichever Java first gets the non incubator > version > > > > > of the API (it could be 19 or 20). > > > > > > > > I may have asked this already: would this be expected to work with > > > > LibreSSL? I think they have a goal of binary-compatibility with > OpenSSL. > > > > > > > > Similarly, Stefan @ httpd has produced an experimental mod_tls for > httpd > > > > which uses RustTLS as its underlying crypto library instead of > OpenSSL. > > > > It might be interesting to see how difficult it would be to use > RustTLS > > > > instead of OpenSSL, though that may require some significant changes > to > > > > Tomcat's code to deal with any "philosophical" differences between > the > > > > OpenSSL API and RustTLS. > > > > > > This supports the OpenSSL 1.1+ API. It doesn't support older versions > > > (it may require adding back some annoying code, or worse), and this > > > will work on newer versions as long as all the APIs in use stay there. > > > No idea about clones, but the libraries have to be really compatible > > > with OpenSSL 1.1, or I would have to stop using jextract (not a great > > > plan). > > > > > > > I fully expect a presentation at the next ApacheCon about all the > work > > > > you are doing. :) > > > > > > Maybe, but there's still a long way to go ;) > > > > > > Rémy > > > > > > > > > > > -chris > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
