Manually bundled OpenSSL artifacts have security advisories

[mbauman]

The OpenSSL artifacts that are hardcoded in Artifacts.toml have been identified as being vulnerable to multiple CVEs, including one of moderate severity (CVE-2026-31790). Now that OpenSSL_jll has been updated to 3.5.6, I'd like to update Julia's SecurityAdvisories.jl to include these advisories. That will happen upon merging JuliaLang/SecurityAdvisories.jl#346, but we try to avoid publishing advisories without an available upgrade pathway.

In general, it's much better to incorporate JLLs as direct dependencies rather than re-incorporating their artifacts — and this is precisely one reason to do so!

[JanisErdmanis]

Thanks for flagging this — I'll update Artifacts.toml in the next patch release.

For context on why the artifacts are pinned this way: the openssl executable is no longer accessible from OpenSSL_jll starting with Julia 1.12, and resolving this cleanly has been a headache. Two avenues I've explored:

• An OpenSSL_CLI_jll recipe: [JuliaPackaging/Yggdrasil#12452]([OpenSSL_CLI] repackaging openssl cli utility JuliaPackaging/Yggdrasil#12452)
• Restoring the openssl executable within Julia itself: [JuliaLang/julia#60176](Restoring OpenSSL executable JuliaLang/julia#60176)

The first approach is awkward because OpenSSL doesn't support building the CLI utility separately, so one either has to rebuild it from scratch or, as I attempted, reuse OpenSSL_jll and repackage it via a BinaryBuilder recipe. The second approach requires bundling the openssl executable into the Julia installation itself.

As for why AppBundler needs openssl at all: it's used to extract the certificate subject and inline it into AppxManifest.xml. If the subject doesn't match the signer when the MSIX is packed, the signature is invalid. Requiring users to type the subject manually would make the first-time experience quite frustrating — and AppBundler's goal is to get the basics working out of the box, with customization available afterward. openssl is also used to generate self-signed certificates for testing and onboarding.

On the security side, I think the practical attack surface here is fairly narrow. The plausible scenarios — a hypothetical vulnerability that leaks a freshly generated self-signing key, or one that compromises the Julia process during an openssl invocation to exfiltrate secrets — seem high-effort and low-reward enough that I don't view them as pressing. That said, I agree that depending on JLLs directly is the better pattern, and this situation is a good illustration of why: with OpenSSL releasing updates as frequently as it does, a pinned artifact will always lag behind.