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

>> Sadly, people tend to prefer adding
>> 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 /
> 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.


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

Reply via email to