Hi, On Sun, Mar 4, 2018 at 11:47 AM, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote: > On Sun, Mar 04 2018, Gert Doering <g...@greenie.muc.de> wrote: > > [...] > >> "Please note that LibreSSL is not a supported crypto backend. We >> accept patches and we do test on OpenBSD 6.0 which comes with >> LibreSSL, but if newer versions of LibreSSL break API compatibility >> we do not take responsibility to fix that." >> >> >> I think a patch adding these LIBRESSL_VERSION checks has a reasonable >> chance of being ACKed and merged :-) - but LibreSSL support stuff has >> to come from some who cares, so Steffan or Antonio are not going to >> go out and check patches for "will it break LibreSSL?"... > > I don't think adding "&& !defined(LIBRESSL_VERSION_NUMBER)" in more > places would be a good idea. Those checks would do more harm than good > in the long run, preventing the use of new interfaces when they get > implemented by LibreSSL. Better use function availability checks IMHO.
Libressl developers break API compatibility with openssl in such perverse ways that there are no easy ways to support it. Take, for example, the patch I just sent out which checks for certain functions instead of disabling using LIBRESSL_VERSION_NUMBER. It finds two "set" functions defined in libressl but two related "get" ones are not found. So the compat layer will get used for those. But there is no guarantee that such mixed usage leads to logically correct code. In fact, the compat layer functions for min/max proto-version are not the same as those in openssl 1.1. Those are a work around meant for cleanly handling multiple versions of openssl without using ifdefs all over the code. If libressl has implemented those set functions as in openssl 1.1, then those get functions from compat layer would not be what you should be using, but that's what you will get. So IMO, it may be more worthwhile for those invested in libressl to convince the developers to make more sane decisions. Either they want libressl to be a better openssl or a different crypto library. They can't behave as neither and both at the same time and expect users/developers to work around their personal opinions of what openssl should be. Selva ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
