orbea commented on PR #13: URL: https://github.com/apache/tomcat-native/pull/13#issuecomment-1194648448
> there would need to be an appropriate Panama module What exactly is this? > 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. 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 https://www.cvedetails.com/product/383/Openssl-Openssl.html?vendor_id=217 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. > 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. 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
