native: Update for libressl 3.5 #13
Conversation
|
I have an open umbrella ticket for LibreSSL in general. @markt-asf Should we continue to pursue to support LibreSSL? |
|
If at all possible I would greatly appreciate if libressl support was not dropped since some people do still use it, although I would not mind dropping support for older libressl versions. With libressl 3.5 a lot of progress was made in bridging the gap between openssl and libressl. |
I agree with you. Diversity is important, though I guess with 2.x we can safely raise the baseline here as well.... |
The earliest supported version is 3.5.2 which is the first stable release of the 3.5.x versions. This is the minimal required to fix the build.
Only libressl 3.5.2 and newer are supported.
|
@michael-o I updated the first commit to remove the outdated code instead and set the first supported version as libressl |
Looking at the Gentoo discussion, for me as a BSD guy I don't see any reason to support LibreSSL compared to OpenSSL 3.0.0. Am I wrong? What are the compelling reasons from the against the discussion? |
|
My main reasons are that libressl has a better track record with security and a significantly better build system. I also think its important to have viable alternative ssl implementations since it is so mission critical. To be clear the main libressl user is OpenBSD who also maintains the project, but at least a few people are trying to still use it on Gentoo. As I understood one of the main concerns with keeping libressl was the maintenance burden, but with libressl 3.5 I was able to remove around 30 packages from the Gentoo overlay where the packages from the main repo worked instead. |
On this I totally agree.
I would recommend to raise this on dev@tomcat.apache.org. |
|
dev@tomcat.a.o is cc'd on all these comments automatically. I've no objection to libressl support in native 2.0.x. Nor to 3.5.2 being the minimum version. Longer term, if there is demand for continued libressl support, there would need to be an appropriate Panama module |
Really? Mostly what they did was discard old garbage from OpenSSL that may have had bugs lurking in it. Anything which demonstrably improves security should have also been picked-up by OpenSSL.
This is irrelevant, as downstream uses don't worry about build complexity. Build complexity may be a source of other issues, but it's not a good justification for wanting to use one library versus another. That being said, I am a big proponent of LibreSSL support if for no other reason than than to avoid a monoculture. Unfortunately, OpenSSL vs LibreSSL is a bit like comparing modern MS Edge, Chrome, and Opera and saying they are different browsers when they are significantly identical under the covers. |
I have built both on many platforms. It was a snap to build OpenSSL even on HP-UX. At runtme, this does not matter.
Here I do support @ChristopherSchultz. I want to avoid mono culture as well, but all of them are Chromium in different clothes. From a runtime perspective, what is now better with LibreSSL compared to OpenSSL. @ChristopherSchultz You maybe remember that I have started to improve the LibreSSL intergration, but it requires a lot of a time and I don't use LibreSSL. OpenSSL throughout. |
What exactly is this?
There used to be a comparison graph for libressl and openssl security issues showing how many security issues openssl introduced have never affected libressl, but its been years since I seen it and I am not sure where that was. However comparing the number of CVEs for libressl and openssl is a huge difference. Arguably more people are submitting them for the latter. Also arguably OpenBSD has a reputation for security and being overly cautious maintainers. Other people are welcome to disagree and use what they feel most comfortable with of course. https://www.cvedetails.com/product/30688/Openbsd-Libressl.html?vendor_id=97 I don't have the qualifications to conclusively argue which one is a better or worse ssl implementation, but I entirely agree in avoiding a monoculture. Having more than one C compiler (gcc and clang) has only been a good thing for example.
As someone involved with maintaining packages for distros I have spent a significant amount of time working on build systems I did not write and this is an very important detail to me personally, but I completely understand that this is not important for most people. Also there are niche cases where the openssl build system is just not adequate for some platforms such as midipix (https://midipix.org/) where I have been told its not easy to fix and that is one of the reasons they use libressl. |
The plan is to migrate to Panama to avoid having to ship libtcnative at all, at which point everything is in Java. Right now, all the glue for the crypto library is in native C code in libtcnative which is potentially dangerous. Moving to Panama allows us to remove all native code that doesn't belong to the crypto library.
I'm going to really need a citation here. Forking a library, removing all the irrelevant code and claiming you have a new product with no security issues isn't really fair from a comparison perspective. If I fork OpenSSL to create ChriSSL tomorrow and just delete all the sources, I guarantee it'll never have any CVEs filed against it.
Yes, CVEs are typically assigned to a single product. I'd be interested to see how many CVEs from the past few years filed against OpenSSL were also (silently) fixed in LibreSSL who gets a pass for those same issues.
I haven't studied the code, but I know a great deal of effort was put into simply removing code deemed unnecessary by the LibreSSL team. I have no idea how much re-writing of any code they have done since then. My guess is that they are still largely the same (minus the removals, of course). |
I still don't understand how it is going to solve |
I'm not sure I understand. All the native code does away, so the "support" for LibreSSL goes into the Java code (the "Panama module") instead of libtcnative. I think @markt-asf's comment could be re-phrased as "let's plan to build LibreSSL support into the native-code-less Panama efforts already underway, rather than hacking them into the libtcnative C code we are hoping to phase-out." |
| @@ -233,7 +233,7 @@ AC_DEFUN([TCN_FIND_SSL_TOOLKIT],[ | |||
| #include <stdio.h> | |||
| #include <openssl/opensslv.h> | |||
| int main() { | |||
| if (OPENSSL_VERSION_NUMBER >= 0x3000000fL) | |||
| if (OPENSSL_VERSION_NUMBER >= 0x3000000fL || LIBRESSL_VERSION_NUMBER >= 0x3050200fL) | |||
| return (0); | |||
There was a problem hiding this comment.
This breaks the build when LibreSSL is not present. I'll get that fixed.
Tested with libressl-3.5.3 on Gentoo using the libressl overlay (https://github.com/gentoo/libressl). Alternatively the code for older libressl versions could be removed, either way it doesn't really matter to me. I'm also not sure what is the last libressl version to work with tomcat-native.