Am 2020-12-06 um 11:03 schrieb Mark Thomas:
On 05/12/2020 11:38, Michael Osipov wrote:
<snip/>
A suitable roadmap for libtcnative would be:
* Tag current patch version
* Move to 1.3.0 and remove everything non-TLS/networking related out
* Move to 1.4.0 drop OpenSSL support for < 1.1.1 because it requires
thread locks from APR which aren't necessary with 1.1.1
* Likely split code between OpenSSL to Java and APR to Java with that we
could satisfy both sides.
There are a couple of complicating factors.
The first is that we try not to remove or change existing API users are
likely to be using in a major version. Addressing security issues is the
exception to that rule. That means that org.apache.tomcat.jni will be
supported until 9.0.x is EOL. Best guess in 6 to 7 years from now.
I agree, that would be a bad move within the same major version.
The other major factor is that Tomcat Native ships with at least one
downstream distro (Debian? or was if FreeBSD?) where only older versions
of OpenSSL are available. We'd like to be nice and not make things too
complicated for the package maintainers.
Well, isn't that really a OS vendor problem not ours? We can provide
grace periods, but that's pretty much it. They need to solve that, not
us on a volunteer basis. The admin/user/X can always compiled from code
a brand new version and nothing hinders him to do so.
FreeBSD's port of libtcnative is uptodate. I provide patches on regular
basis. Vendors like Debian or Red Hat lag years behind.
In the back of my mind I have had something along the following lines
which isn't too far from your proposal.
1. Create Tomcat Native 2.0 for Tomcat 10.1.x onwards that provides only
what is required to integrate OpenSSL with NIO and NIO2. Ideally,
without a dependency on APR. Given likely minimum JRE version
requirements of future Servlet specs, I think it will be a while before
we can take advantage of any JRE features intended to simplify native
integration.
Makes sense.
2. Continue to support Tomcat Native 1.x for Tomcat 8.5.x and 9.0.x
(10.0.x will be EOL with the first stable 10.1.x release)
Agreed, I'd be happy to for the platforms I use.
3. Once downstream distributions have access to 1.1.1 move Tomcat Native
1.2.x to 1.3.x and remove all the OpenSSL <1.1.1 code. We can make 1.3.x
recommended for Tomcat 8.5.x and 9.0.x (or even required if necessary /
appropriate).
This will take years. Won't it?
4. At the same time as 3 we probably want to review similar code for old
Windows versions, old Linux kernels etc and drop support for some of
those where appropriate too.
Looking at the APR/OpenSSL code I haven't seen anything particular
requiring any specific OS or kernel version. That's plain POSIX
abstracted with APR and OpenSSL internals. But yes, skimming is good.
I suspect there would be a Tomcat 1.4.x at some point to make OpenSSL 3
the minimum version.
So you would continue to support two native code trees? Wouldn't make
even more work than today?
If we wanted to provide space for Tomcat/Native to continue providing
the level of APR support it does today, rather than Use Tomcat Native
2.x for the OpenSSL integration we could use a new name (Tomcat TLS
Native maybe?) leaving Tomcat Native free to evolve into 2.x, 3.x and
beyond.
This makes sense. Maybe a split from Tomcat Native would be a better
alternative supporting APR only and OpenSSL only. So two libraries, not
interrelated.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
