OpenSSL_jll alignment is stricter than necessary for ABI compatibility

[iamed2]

OpenSSL policy states:

A minor release is indicated by changing the second number of the version. A minor release can, and generally will, introduce new features. However both the API and ABI will be preserved.

For example, a program built with OpenSSL release 3.0.1 will be able to run with OpenSSL 3.1.0 but might not be able to take advantage of new features without modification.

The CondaPkg.jl source code shows:

    if version.major >= 3
        # from v3, minor releases are ABI-compatible
        return ">=$(version.major), <$(version.major).$(version.minor+1)"

I believe if the reason is ABI compatibility, the restriction should be:

    if version.major >= 3
        # from v3, minor releases are ABI-compatible
        return ">=$(version.major), <$(version.major+1)"

[cjdoris]

No the current behaviour is intended, and is indeed for ABI compatibility.

The bounds are chosen assuming that the Julia OpenSSL package is loaded before the Python one. Suppose that Julia is on OpenSSL 3.0. In your proposal, we allow Python to install OpenSSL 3.3. Now because Julia's OpenSSL package is loaded first, version 3.0 of the libopenssl library is loaded into memory. Then when Python's OpenSSL package is loaded, it does not override libopenssl, it just uses whatever is already in memory, namely 3.0. However because Python is on OpenSSL 3.3, the Python OpenSSL package will expect to be able to use features present in the 3.3 ABI of libopenssl. If it tries to do so it will crash, because 3.3 is not actually loaded, an older version is loaded.

Therefore the Python OpenSSL package needs to be older than the Julia one, which is the current behaviour.

[cjdoris]

You can now set JULIA_CONDAPKG_OPENSSL_VERSION=ignore if you'd like to turn off this behaviour. See the README for more info.