Mark,
On 6/21/22 11:42, Mark Thomas wrote:
On 16/06/2022 11:10, Mark Thomas wrote:
OpenSSL will be producing security releases on 21st June. This will
include 3.0.4.
The security issue affects a script distributed with OpenSSL. The
binaries for Windows that Tomcat distributes are not affected.
OpenSSL 3.0.3 won't build for Windows using our build tool chain
because of a dependency on a method that doesn't exist in the runtime
libraries we build against. The fix will be in 3.0.4.
I have been able to build OpenSSL 3.0.x HEAD for Windows using our
build tool chain.
Given all of the above, my plan for Tomcat Native 2.0.0 is as follows:
- test the build once OpenSSL 3.0.4 is released, including running
the 10.1.x unit tests with it
I'll be doing this later today.
- tag and release Tomcat Native 2.0.0
- update Tomcat 10.1.x to use Tomcat Native 2.0.x
- tag and release Tomcat 10.1.x
A separate question is do we want to continue building Tomcat Native
1.2.x with OpenSSL 1.1.1 or do we want to switch to OpenSSL 3.0.x?
I'm on the fence on this one. I have configured Gump to build Tomcat
Native 1.2.x with both OpenSSL 1.1.1 and 3.0.x. I am heading (one step
at a time) towards:
Test 10.1.x with Tomcat Native 2.0.x and OpenSSL 3.0.x
Test 10.0.x with Tomcat Native 1.2.x and OpenSSL 3.0.x
Test 9.0.x with Tomcat Native 1.2.x and OpenSSL 3.0.x
Test 8.5.x with Tomcat Native 1.2.x and OpenSSL 1.1.1
Assuming the tests pass (I expect they will) then we can decide which
version of OpenSSL to use for the Windows binaries.
Personally, I am leaning towards using 3.0.x as that makes a FIPS
solution a possibility (once the FIPS module is certified).
You mean "building the statically-linked native library for inclusion in
Windows distributions" right? If so, I think switching to OpenSSL 3.0 is
okay. There may be some who don't want / can't take the upgrade, even
just because auditing the dependency-change is a giant hassle.
Would it be terribly difficult to produce two binaries?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
