OpenSSL 3.0, 3.1 (and 3.2)

[PallHaraldsson]

It's great to see 3.0 supported in Julia. I just thought should the Julia wrapper version also be 3.0? At least if it was a breaking change.

It's unclear if it was, maybe only in some situations (that do not apply to Julia?):
https://www.openssl.org/docs/man3.0/man7/migration_guide.html

https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/

One reason for 3.0 version was new Apache license, mention it here?

I did also see some security fixes:

Fixed in OpenSSL 3.1.1 (gi commit) (Affected since 3.1.0)
Fixed in OpenSSL 3.0.9 (git commit) (Affected since 3.0.0)
[..]

If affecting Julia (we're still at "OpenSSL_jll v3.0.8"?), go straight to 3.1 (or 3.2? is that a dev version?)?

[quinnj]

There's no need to match versions of the OpenSSL.jl package (wrapper of the library) and the C library.

On the latest OpenSSL_jll version, we could ping @mkitti and see if he has plans to do the binary build update?

[mkitti]

This package, OpenSSL.jl, is currently compatible with OpenSSL v1.1 and OpenSSL v3.0 as of OpenSSL.jl v1.4.0.

We are currently tracking OpenSSL v1.1 and OpenSSL v3.0 upstream in OpenSSL_jll:
https://github.com/JuliaPackaging/Yggdrasil/tree/master/O/OpenSSL

Both v1.1.1 and v3.0 are both LTS versions. OpenSSL v1.1.1 is end of life effective September 11th, 2023. OpenSSL v3.0 will be supported until September 7th, 2026. All Julia dependents are encouraged to upgrade to OpenSSL_jll v3.0 as soon as possible.
https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/

OpenSSL v3.1 is supported through March 14th, 2025. Julia security doctrine is such that we should only track LTS versions for security sensitive packages. We need to the avoid a similar situation to when Julia 1.6 LTS adopted a non-LTS mbedTLS 2.24. Thus, I have no intention of introducing OpenSSL v3.1 to Yggdrasil.

To my knowledge OpenSSL v3.0.9 and v1.1.1u have not been released upstream yet. The CVE is of low severity.

[PallHaraldsson]

There's no need to match versions of the OpenSSL.jl package (wrapper of the library) and the C library.

If/in that case I close the issue. I thought it might still be a good idea to match, and not disallowed by SemVer. It would clearly show people we support 3.0, but people might assume it's a breaking change. If the wrapped library is in fact breaking then we would need to update the number anyway, and then 3.0 best skipping 2.0.