On Tue, Nov 23, 2021 at 9:33 AM Martin Grigorov <mgrigo...@apache.org> wrote:
>
> 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!
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.
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: 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
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
