You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2022/06/01 15:09:40 UTC

Re: Tomcat Native 2.0 Update

On 31/05/2022 09:33, Rémy Maucherat wrote:
> On Tue, May 31, 2022 at 9:46 AM Mark Thomas <ma...@apache.org> wrote:
>>
>> On 30/05/2022 20:05, Rémy Maucherat wrote:
>>> On Mon, May 30, 2022 at 6:49 PM Mark Thomas <ma...@apache.org> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I have made some progress. I have a trimmed down Tomcat Native 2.0 built
>>>> with OpenSSL 3.0 working locally with Tomcat 10.1.x. I also have it
>>>> working with the OpenSSL 3 FIPS provider.
>>>>
>>>> I have also been thinking about Tomcat Native 1.2.x and 2.0.x
>>>> interoperability.
>>>>
>>>> Since Native 2.0 is mostly (apart from one new FIPS method) a subset of
>>>> Native 1.2 it should be relatively easy for 10.1.x to work with Native
>>>> 2.0.x or 1.2.x.
>>>>
>>>> Allowing Native 1.2.x use with Tomcat 10.1.x should make it easier on
>>>> downstream distributions as it removes the need for them to update to
>>>> APR 1.7.x and OpenSSL 3.0.x
>>>>
>>>> Getting 10.0.x and earlier working with Native 2.0.x is a little
>>>> trickier although it doable if the limits are:
>>>> - No APR/Native connector
>>>> - No application usage of o.a.t.u.jni (as most of the native code is
>>>>      removed)
>>>>
>>>> Enabling Native 2.0.x use with Tomcat 10.0.x and earlier opens up the
>>>> possibility of OpenSSL FIPS that doesn't depend on an unsupported
>>>> version of OpenSSL.
>>>>
>>>> I am currently thinking along the following lines:
>>>>
>>>> - release Tomcat Native 1.2.34 that includes:
>>>>      - refactoring the caching of the FileInfo and Sockaddr classes so
>>>>        that are only cached if used
>>>>      - any additional refactoring to allow Native 1.2.x to be used in
>>>>        Tomcat 10.1.x with all the deprecated code removed
>>>>
>>>> - make Tomcat Native 1.2.34 the minimum required Tomcat Native version
>>>>      for Tomcat 10.1.x
>>>>
>>>> - release Tomcat Native 2.0.0
>>>>
>>>> - make Tomcat Native 2.0.0 the minimum recommended Tomcat Native
>>>>      version for Tomcat 10.1.x
>>>>
>>>> - updates as required to Tomcat Native 1.2.x, 2.0.x and Tomcat
>>>>      <=10.0.x to allow Tomcat Native 2.0.x to be used (reasonably) safely
>>>>      with Tomcat <=10.0.x
>>>>
>>>> My plan is to do most of this work locally to make sure I haven't missed
>>>> anything and then start committing and releasing in the order above.
>>>
>>> Sounds great. Any subtask for me or do you prefer doing it alone ?
>>
>> Thanks for the offer of help.
>>
>> I have a lot of the above ready locally already and everything is
>> inter-related making it hard to extract independent sub-tasks. With all
>> the inter-dependencies I might miss something so if you could keep that
>> in mind when reviewing my commits that would be helpful.
>>
>> The tasks below, particularly the first and third, are largely
>> independent. If you have time to look at either of those that would be
>> great. I'll try and commit the bulk of the initial changes for Tomcat
>> Native 2.0.x today.
> 
> Ok !
> 
> About the first item, I don't recall any deprecated call being used
> for the OpenSSL 3.0 code path when I converted to Panama, but I will
> review again.

I have completed my updates to Native for now.

I have a couple of commits for Tomcat (all versions) that will need to 
wait for the Tomcat Native 1.2.34 release since they depend on changes 
since 1.2.33. I plan to work on a Native release during June.

When I compile 2.0.x with OpenSSL 3.x I get a bunch of warnings about 
using deprecated OpenSSL API.

> About LibreSSL, it is not a good target for the Panama code. First
> reason is without ifdef then it makes things more complex. Second
> reason is possible use of extra APIs that would be only in OpenSSL
> (for example if they ever add the promised high level API for QUIC
> support).

ACK.

The further LibreSSL and OpenSSL diverge, the harder it is going to be 
to support both.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org