Hi, On 20-11-17 09:06, Gert Doering wrote:> On Sun, Nov 19, 2017 at 11:01:39PM +0100, Jeremie Courreges-Anglas > wrote: >>> (Not sure, though, why it only complains about two out of >>> three, but still annoyance... if LibreSSL claims >>> OPENSSL_VERSION_NUMBER >= 0x10100000 it better should provide >>> everything needed) >> >> LibreSSL defines: >> >> #define OPENSSL_VERSION_NUMBER 0x20000000L >> >> breaking #ifdef checks based on it. > > Indeed. I find this a curious and not useful setting - "if it's > not compatible with OPENSSL, why define such a version number"? > But that's slightly out of scope here...
+1, highly frustrating. LibreSSL should really just make up their mind whether they want to be OpenSSL-compatible or not, and act accordingly. >> Sadly, people tend to prefer adding >> >> && !defined(LIBRESSL_VERSION_NUMBER) >> >> to fix the build, rather than doing features detection using >> autoconf or similar. openvpn can easily solve this. > > ... and I'm thankful for your patch, because this is exactly what I > considered doing here. We already check for all the 1.0/1.1 > openssl differences (accessor functions), so adding this one is > logical. *If* we want to keep LibreSSL working, I agree this is the way to go. But I'm kind of annoyed that we are including more and more #ifdefs to keep LibreSSL happy. The version checks are much simpler and make it easy to see what code can be purged when we drop support for e.g openssl 1.0.1. I don't want to keep these 'backwards compatibility' ifdefs forever. At some point we'll have to decide to either completely stop supporting LibreSSL, or add it as a true abstraction (which I will *not* maintain). We're getting closer and closer to that point. >>> This is on OpenBSD 6.0, which happens to be something Samuli's >>> vagrant setup can provide nicely if anyone wants to have a look >>> :-) >> >> Here's a diff, master builds and seems to run fine as a client >> on OpenBSD-current. > > Thanks. Patch looks good to me, but I leave the final word to > Steffan (maybe he wants to amend the non-support message to include > LibreSSL, or whatever) They look good at first sight, but I'll check these properly later this week - when I have some spare cycles available. >> I can cook a similar diff for the remaining OPENSSL / >> LIBRESSL_VERSION_NUMBER #ifdef. > > This would be appreciated. Same reservations as above. To reiterate: our policy towards LibreSSL is currently that we do *not* support it, but we won't break it on purpose and accept trivial patches to keep it working. Where 'trivial' is - of course - fuzzy. -Steffan ------------------------------------------------------------------------------ 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
