Hi Remy,
On Tue, Nov 23, 2021 at 9:49 AM Rémy Maucherat <r...@apache.org> wrote:
> On Mon, Nov 22, 2021 at 10:55 PM Christopher Schultz
> <ch...@christopherschultz.net> 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!
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.
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: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
