On Thu, Oct 28, 2021 at 4:06 PM Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> Rémy,
>
> On 10/26/21 07:46, Rémy Maucherat wrote:
> > During the past weeks, I examined the state of the Panama project and
> > what it could do. I know Mark had a look at it three years ago, and it
> > was not ready yet. This does not appear to be the case anymore and I
> > could produce a wrapper for OpenSSL and a fully functional
> > implementation of the OpenSSLContext/OpenSSLEngine that does not use
> > tomcat-native.
>
> Cool. I've only read the README at this point, but can I ask some questions?
>
> 0. If this is in Java 17, why can't we use a stock Java 17 for this
> purpose instead of using the forked Java 18 development build?
The API has changed significantly already from Java 17, and will
change more. So for now I prefer targeting the upstream API and
benefit from fixes and improvements.
Also, jextract is not available in the JDK, so I would have to find a
version of it that is compatible with the Java 17 API.
Once things are stable, I will likely attempt a backport to the Java 17 API.
> 1. This (currently lengthy) process produces a JAR file, 100% Java code?
Yes !
> 2. It's the JAR file (well, really bytecode) that is huge when
> supporting the entire OpenSSL API?
Yes, if you need the whole OpenSSL API, then it's a bit over 3MB.
Thankfully, I have now verified it can be trimmed down without causing
problems (and add new calls as needed later), so the current size with
everything is 133kB. This is great considering tomcat-native can be
dropped.
> 3. What "problems" are caused by the large size of that library?
Well, there was the problem of the amount of classes and raw size, but
more significantly the main class can be huge, so loading that
probably takes some cycles.
> > I think this could be integrated in Tomcat as a module like
> > "modules/jdbc-pool". Here, likely "modules/openssl-panama".
>
> 4. Would modules/openssl-panama essentially be a (potentially
> complicated) build script without any code?
Ok for the wrapper generated by jextract. But a new
OpenSSLContext/Engine that uses it is also needed, so that goes in the
module.
Right now, things look good as far as functionality goes. Everything
except OCSP is implemented. I do get crashes under handshake load, so
I likely messed something up somewhere, though. Performance is
equivalent to JNI/tomcat-native, so that's a huge if the end goal is
to drop tomcat-native.
The main downside of the API is that is is detyped. So you write C
code equivalent with only void* pointers, to give you an idea, which
you cast or use wherever you like without any warnings. So whatever
native bits remain are even less safe than before. I don't quite get
why MemoryAddress is not a generic type, like MemoryAddress<SSL>
(jextract does generate an empty SSL type, along with the others, if
you let him) and that would make things nicer. Of course, it is likely
because it's not doable :D
Quick example: it took me hours to get ALPN working. Why ? Because the
OpenSSL API is "smart", and looks like:
int SSL_callback_alpn_select_proto(SSL* ssl, const unsigned char
**out, unsigned char *outlen,
const unsigned char *in, unsigned int inlen, void *arg)
So you see a few pointers and all is well. However, it was not working
for me, because I was using the length of the array, which is an int.
The pointer is byte size, however. Oops ;)
On a more positive example, tomcat-native sometimes has large amounts
of complex native code, in particular for OCSP support. This can now
be mostly rewritten in Java (besides the initial extraction of the
certificate information).
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
