Find the correct OpenSSL library for FreeBSD

[jasonpugsley]

This is a minor change, it builds and works on my setup - previously dotnet crashed on first-run when trying to send telemetry.

OpenSSL 1.1.1 -> libssl.so.11
OpenSSL 1.0.2 -> libssl.so.8

#34897

@wfurt

[ghost]

Tagging @bartonjs as an area owner. If you would like to be tagged for a label, please notify danmosemsft.

[bartonjs]

It's a little weird that you've replaced the primary recommended name, left fallback names, and then added one more fallback.

I'd sort of expect either the whole list to be replaced, or both library probes to be additive... but one replace, one add is weird.

[jasonpugsley]

As FreeBSD support is WIP at the moment I guess I was trying to make a targeted change to the bits that didn't work on my set-up.

Perhaps this function should just work through a list of versions in order of preference to match on the best library. It would be good if the list wasn't in compiled code but I really have no idea how many possible library versions are needed nor how often they change.

I'm happy to drop this for a better/more standard solution.

[bartonjs]

The escape valve is the CLR_OPENSSL_VERSION_OVERRIDE environment variable. There's not really any other config model that we can really have at this point.

I'd just expect this to be either

• All of the current things, then the FreeBSD things, unconditional (or an argument for why the FreeBSD ones come first)
• All of the current things, then the FreeBSD things, conditionally compiled for FreeBSD (possibly with the FreeBSD ones first)
• The entirety of this list replaced for FreeBSD.

so the versionOverride stuff, then

#if __FreeBSD__
    if (libssl == NULL)
    {
        // OpenSSL 1.1.1 on FreeBSD x.y
        DlOpen(MAKELIB("11"));
    }

    if (libssl == NULL)
    {
         ...
    }
#else
    // all of the current guarded DlOpen(MAKELIB()) calls
#endif

    return libssl != NULL;

[jasonpugsley]

I have removed the #ifdef entirely. I hope this makes sense. I am making the assumption that any non-FreeBSD system that fell through without a match previously will continue to do so. If you disagree, let me know and I'll fence the new code.

[vcsjones]

If you would like to be tagged for a label, please notify danmosemsft.

@danmosemsft is that offer open to contributors?

[danmoseley]

@danmosemsft is that offer open to contributors?

I don't see why not - but I have to do this manually, so perhaps only for the most regular contributors (surely there is some external solution for hooking label changes?). Which labels would you like to be notified for @vcsjones ?

[danmoseley]

@vcsjones actually - I take that back. It would show up that you're the "area owner" and I think that might cause confusion. Let me think about this. Let me know if you find another mechanism, too.

[danmoseley]

Even though you are helping be an area owner, in a sense ! Which we appreciate. Hmm

[wfurt]

I get this on 11.3: So for legacy 1.0, the link is '.8'

[furt@freebsd-11 ~]$ openssl version
OpenSSL 1.0.2s-freebsd  28 May 2019
[furt@freebsd-11 ~]$ ldd /usr/bin/openssl
/usr/bin/openssl:
	libssl.so.8 => /usr/lib/libssl.so.8 (0x8008a4000)
	libcrypto.so.8 => /lib/libcrypto.so.8 (0x800c00000)
	libc.so.7 => /lib/libc.so.7 (0x801076000)

(Installed from ports)
[furt@freebsd-11 ~]$ /usr/local/bin/openssl version
OpenSSL 1.1.1d  10 Sep 2019
[furt@freebsd-11 ~]$ ldd /usr/local/bin/openssl
/usr/local/bin/openssl:
	libssl.so.11 => /usr/local/lib/libssl.so.11 (0x8008b6000)
	libcrypto.so.11 => /usr/local/lib/libcrypto.so.11 (0x800c00000)
	libthr.so.3 => /lib/libthr.so.3 (0x8010ea000)
	libc.so.7 => /lib/libc.so.7 (0x801312000)

I'm wondering if we could/should just fallback to `libssl.so' without version?

[furt@freebsd-11 ~]$ ls -al  /usr/lib/libssl*so
lrwxr-xr-x  1 root  wheel  11 Jul 21  2017 /usr/lib/libssl.so -> libssl.so.8

on 12.1 I get

[furt@daemon ~]$ ldd /usr/bin/openssl
/usr/bin/openssl:
	libssl.so.111 => /usr/lib/libssl.so.111 (0x8002dd000)
	libcrypto.so.111 => /lib/libcrypto.so.111 (0x800375000)
	libc.so.7 => /lib/libc.so.7 (0x800664000)
	libthr.so.3 => /lib/libthr.so.3 (0x800a5d000)

There seems to be difference between 12.1 and 11.3 - both can use OpenSSL 1.1.1 but the linkage is different. Maybe the sequence should belibssl.so.111 -> libssl.so.11 -> libssl.so.8 -> libssl.so ? That would for for all current and future versions.

[jasonpugsley]

Thanks @wfurt I had not looked at other versions of FreeBSD yet.

[jasonpugsley]

Just for the record, I have spun up VMs for 12.1 and a current development snapshot of 13.0.
The openssl version looks like this:
12.1 base has 1.1.1d libssl.so.111 From pkg install it is 1.1.1f libssl.so.11
13.0 base has 1.1.1f libssl.so.111 From pkg install it is 1.1.1f libssl.so.11

I don't know the background on how these library numbers are assigned but unfortunately it doesn't look like we can say libssl.so.111 is going to be newer than libssl.so.11. For the goal of getting this working though, based on the versions in this conversation, I would recommend libssl.so.11 -> libssl.so.111 -> libssl.so.8 -> libssl.so. That order looks like it would preference the higher/newer version of OpenSSL on 11.3, 12.1 and 13.0dev

Of course CLR_OPENSSL_VERSION_OVERRIDE is available if there are more versions out there than these.

[wfurt]

I would be fine with that order. That allows OpensSSL From ports be first. Since none of the existing code uses .so without version and upcoming 13.x seems to be fine and we have fall-back with CLR_OPENSSL_VERSION_OVERRIDE, I would probably drop it leaving just 11->111->8.
I think if you work out changes @bartonjs suggested, we would be good.

[dnfclas]

All CLA requirements met.

[jasonpugsley]

I have updated the code and removed the #ifdef so the FreeBSD specific code will only run if a library hasn't already been found.

[bartonjs]

The failure looks like #2271; and this shouldn't have any real way of exacerbating that problem.