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.
> 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]
