# libressl 3.4.2 upgrade woes



## zirias@ (Jan 16, 2022)

tl;dr: If you build your ports with `DEFAULT_VERSIONS+= ssl=libressl`, you can find _some_ fixes in my local ports branch published here: https://github.com/Zirias/zfbsd-ports

It seems support for LibreSSL in FreeBSD ports is getting ever worse 

Many maintainers developed a mindset of "if upstream doesn't support it, we won't either". That's somewhat understandable as code linking OpenSSL is already riddled with version-checks because the API changes a lot (IMHO pretty bad design), and LibreSSL, in an attempt to be compatible, adds OpenSSL version macros as well, but often, some parts don't exactly match the OpenSSL version claimed. So, consuming code often needs additional checks for LibreSSL as well, and keeping up to date with *that* is a real PITA.

But then, if a specific choice for `DEFAULT_VERSIONS` leads to tons of failed builds, it would probably be better to remove support. Well, support is still there and I didn't give up yet with catching up...

Hitting me this time:

net/freeradius3, again. Fixed.
security/stunnel, again. Fixed as well.
net/asterisk16: This one was new. Especially "funny" to fix as one problem was in a bundled and locally patched (during the build) dependency, so I had to create a patch that creates a new patch in the source tree, oh my 
devel/boost-libs: Only detected because a consumer failed to build. Fixed.
security/openvpn: This is pretty "special", as it doesn't have any problem with building, but the port forbids building when LZO is selected, for licensing issues. I'm pretty sure GPL allows to do whatever with the code (including to link any library you wish, even if it was proprietary), so it probably should *only* forbid to build an official package, but not building one for your own local use. I just removed the restriction altogether, which is fine for me locally...
I didn't do thorough runtime-testing so far, so maybe the fixes still miss something – will see later.


----------

