Bug 68910 - Improve LibreSSL version check in tcnative.m4
Summary: Improve LibreSSL version check in tcnative.m4
Status: NEW
Alias: None
Product: Tomcat Native
Classification: Unclassified
Component: Library (show other bugs)
Version: 2.0.7
Hardware: All All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-04-17 10:09 UTC by Michael Osipov
Modified: 2024-04-18 17:11 UTC (History)
1 user (show)



Attachments
Failed tests (8.29 KB, application/gzip)
2024-04-18 17:11 UTC, Michael Osipov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Osipov 2024-04-17 10:09:08 UTC
Note: Applies to 1.3.x as well and is a followup to 29f0cc900310b1982b462b16fc308cbfeade79d4.

since we also do support LibreSSL I see a few problems here:

> AC_MSG_CHECKING(OpenSSL library version >= 3.0.0)

Does not reflect the minimum LibreSSL version (3.5.2)

Guarantees:
* from 2.2.2 LIBRESSL_VERSION_NUMBER is bumped with each release: https://github.com/libressl/portable/blob/64e0f7c5d644e55e0bbbf985335e42c4f59e615d/ChangeLog#L2761-L2762
* from 2.3.2 LIBRESSL_VERSION_NUMBER matches the output format of OPENSSL_VERSION_NUMBER: https://github.com/libressl/portable/blob/64e0f7c5d644e55e0bbbf985335e42c4f59e615d/ChangeLog#L2589-L2591

So I believe https://github.com/apache/tomcat-native/blob/d1cc229db7416b59f7d6ba2d7bcb8188b5ebffc6/native/build/tcnative.m4#L228-L239 can/should be rewritten to properly print the actual reqiured version number instead of hardcoded 3.0.0. If you run LibreSSL 3.4.x the error output would be confusing.
Comment 1 Christopher Schultz 2024-04-17 14:31:08 UTC
(In reply to Michael Osipov from comment #0)
> since we also do support LibreSSL [...]

Note: Support for LibreSSL is more of an aspiration and less of a requirement. We don't technically advertise support for LibreSSL, but I would like to be able to support it.
Comment 2 Michael Osipov 2024-04-17 14:48:25 UTC
(In reply to Christopher Schultz from comment #1)
> (In reply to Michael Osipov from comment #0)
> > since we also do support LibreSSL [...]
> 
> Note: Support for LibreSSL is more of an aspiration and less of a
> requirement. We don't technically advertise support for LibreSSL, but I
> would like to be able to support it.


Right, let me rephrase: best effort. Still at least here we can present a better message and may a warning that LibreSSL is best effort.
Comment 3 Michael Osipov 2024-04-18 07:08:15 UTC
(In reply to Christopher Schultz from comment #1)
> (In reply to Michael Osipov from comment #0)
> > since we also do support LibreSSL [...]
> 
> Note: Support for LibreSSL is more of an aspiration and less of a
> requirement. We don't technically advertise support for LibreSSL, but I
> would like to be able to support it.

FYI. Just ran 10.1.x with LibreSSL 3.5.2:
   [concat] TEST-org.apache.catalina.valves.rewrite.TestResolverSSL.NIO.txt
   [concat] TEST-org.apache.catalina.valves.rewrite.TestResolverSSL.NIO2.txt
   [concat] TEST-org.apache.tomcat.util.net.TestClientCert.NIO.txt
   [concat] TEST-org.apache.tomcat.util.net.TestClientCert.NIO2.txt
   [concat] TEST-org.apache.tomcat.util.net.TestCustomSslTrustManager.NIO.txt
   [concat] TEST-org.apache.tomcat.util.net.TestCustomSslTrustManager.NIO2.txt
   [concat] TEST-org.apache.tomcat.util.net.openssl.TestOpenSSLConf.NIO.txt
   [concat] TEST-org.apache.tomcat.util.net.openssl.TestOpenSSLConf.NIO2.txt

The rest is passing. These are failing for renegotiation or protocol mismatch. That looks very promising.
Comment 4 Christopher Schultz 2024-04-18 12:29:10 UTC
Thanks for doing this work; it IS promising.

Can you share the details of the failures?
Comment 5 Michael Osipov 2024-04-18 17:11:05 UTC
Created attachment 39673 [details]
Failed tests

(In reply to Christopher Schultz from comment #4)
> Thanks for doing this work; it IS promising.
> 
> Can you share the details of the failures?

Find failed tests attached.