[openssl] add new port openssl 3.0.0

[xavier2k6]

Library name: OpenSSL v3.0.0

Library description:
OpenSSL is a robust, commercial-grade, and full-featured toolkit for the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. It is also a general-purpose cryptography library.

Source repository URL:
https://github.com/openssl/openssl/releases

Project homepage (if different from the source repository):
https://www.openssl.org/

Anything else that is useful to know when adding (such as optional features the library may have that should be included):
https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/
https://github.com/openssl/openssl/releases
https://www.openssl.org/news/changelog.md
https://www.openssl.org/news/changelog.html#openssl-30
https://github.com/openssl/openssl/blob/master/doc/man7/migration_guide.pod

[JonLiu1993]

@xavier2k6 ,At present, there is already an openssl port in vcpkg. Is there any difference between it and this port?

[xavier2k6]

I know OpenSSL 1.1.1.L port is available in vcpkg, I just wasn't sure when opening issue if it should be treated as an update/upgrade or whether it should be treated as separate - I went with the latter. (erred on the side of caution)

[AenBleidd]

I think it should be a separate port: since it's not fully backward compatible with 1.1.1*, a lot of ports that use it will be immediately broken

[ras0219-msft]

However, without replacing openssl, users won't actually get anything built on top of the new library.

Our end goal is that this should be checked in as openssl and the ecosystem moves forward. At that point, users wanting the old version will always have access to it via versioning. It will likely be a long process to get it merged and, in the meantime, users can grab the PR to get early access to the new version.

[AenBleidd]

@ras0219-msft, does this mean that all ports, that have openssl as a dependency and are not yet support openssl3, will have openssl version fixed in their vcpkg.json file?
This will then mean that all this ports should be more actively monitored to update their vcpkg.json files when minor update of openssl 1.1.* will be released.
TBH, I don't think that having two major versions with breaking changes inside one port is nice for port consumers.

[FranciscoPombal]

@ras0219-msft

However, without replacing openssl, users won't actually get anything built on top of the new library.

Our end goal is that this should be checked in as openssl and the ecosystem moves forward. At that point, users wanting the old version will always have access to it via versioning. It will likely be a long process to get it merged and, in the meantime, users can grab the PR to get early access to the new version.

Unfortunately, I expect migration to 3.0 to be slow, and probably most importantly, I expect it will happen at vastly different rates among all of its dependents in the vcpkg repository. Won't this frequently result in unsatisfiable versioning constraints when installing ports (e.g. a user requires 5 packages that depend on OpenSSL < 3 and 5 that depend on OpenSSL >= 3)?

So, instead of recommending users to rely on versioning or introducing a new openssl3 port besides the existing openssl one, what about doing something similar to the latter, but the other way around?

1. Rename the current openssl port to openssl_1.1.1 or similar (this obviously requires also updating the port files for all dependents).
2. Introduce a new openssl3 port.
3. Gradually migrate all OpenSSL dependents to openssl3.

[xavier2k6]

OpenSSL 3.0.1 out now:

https://www.openssl.org/news/cl30.txt
https://www.openssl.org/news/newslog.html
https://www.openssl.org/
https://www.openssl.org/source/
https://github.com/openssl/openssl/tags

[talregev]

I think it should be a separate port: since it's not fully backward compatible with 1.1.1*, a lot of ports that use it will be immediately broken

I think the same.
Also we have an example that already happen in opencv. we have new port for each major version.

[ras0219-msft]

Won't this frequently result in unsatisfiable versioning constraints when installing ports (e.g. a user requires 5 packages that depend on OpenSSL < 3 and 5 that depend on OpenSSL >= 3)?

That is exactly what happens but worse if we ship openssl3 as a separate port. Some number of libraries will point at openssl3, some will point at openssl, and the user will get undefined behavior at runtime. The terrible part of situation is that many of those libraries would actually work fine with either and we've created unnecessary problems by shipping it as two names.

This is why it is absolutely critical for openssl to resolve to a single version, ensuring that these sorts of diamonds have all been worked out for the user. From the OpenSSL update page:

It is the intention that the large majority of applications will work unchanged with OpenSSL 3.0 if those applications previously worked with OpenSSL 1.1.1

so we will need to see what the precise fallout of this upgrade will be. Glancing through the upgrade guide (https://www.openssl.org/docs/man3.0/man7/migration_guide.html) it looks like the vast majority of changes are additive. Some things have been marked as deprecated but still exist. The most significant change listed looks to be

Not all algorithms may be available for the application at a particular moment. If the application code uses any digest or cipher algorithm via the EVP interface, the application should verify the result of the EVP_EncryptInit(3), EVP_EncryptInit_ex(3), and EVP_DigestInit(3) functions. In case when the requested algorithm is not available, these functions will fail.

My reading is that this should be fine for most library code. The end application may choose what libraries to load or unload into the new provider interface, but libraries should function as correctly as possible given the circumstances.

[Hoikas]

Will there be a way for OpenSSL 1.1.1 users to consume security patches to OpenSSL 1.1.1 via vcpkg if the openssl port is updated to OpenSSL 3? I am getting reports in my project that Homebrew updating their OpenSSL to OpenSSL 3 is causing issues in our 1.1.1 code, so I am very interested in seeing a centralized solution for that.

[Thomas1664]

Openssl 3 can only be merged if all downstream ports fix their issues related to openssl 3!

Many people are waiting for vcpkg to support openssl 3 and the only thing that holds us back are ~10 out of many packages that don't support openssl 3!

Because vcpkg doesn't support the same versioning like npm, we can't just add breaking changes.

That is exactly what happens but worse if we ship openssl3 as a separate port. Some number of libraries will point at openssl3, some will point at openssl, and the user will get undefined behavior at runtime. The terrible part of situation is that many of those libraries would actually work fine with either and we've created unnecessary problems by shipping it as two names.

In this case the entire versioning idea is kind of useless if all dependant ports need to support the latest version anyway! The only benefit is that end uses that don't create a new port can choose which version they want to use. Instead, we need a way to resolve version conflicts.

The only solution is to find out why those ports don't support openssl 3. In the linked PR is a list of all of these ports.

[talregev]

and the user will get undefined behavior at runtime. The terrible part of situation is that many of those libraries would actually work fine with either and we've created unnecessary problems by shipping it as two names.

I don't agree at all. Take a look on opencv and you will see there isn't undefined behavior as you say.
The opposite will happen if you ship openssl3 as openssl. a lot of port will break and will not compile, or run with unexpected behavior. (undefined behavior at runtime) because openssl3 is not backward compatibility.

This is why it is absolutely critical for openssl to resolve to a single version, ensuring that these sorts of diamonds have all been worked out for the user. From the OpenSSL update page:

It not critical that openssl have to be in a single version, and stop intimidate people and developers.

[talregev]

I have a suggestion.
To switch openssl to be 3.0.0
and create openssl1 for 10 packages that doesn't support openssl 3, until they switch.
@ras0219-msft @JackBoosY
What do you say?

[JackBoosY]

I have a suggestion. To switch openssl to be 3.0.0 and create openssl1 for 10 packages that doesn't support openssl 3, until they switch. @ras0219-msft @JackBoosY What do you say?

I think that's acceptable, but we should skip all triplets in ci.baseline.txt, and warning users that they are conflicts.

[Thomas1664]

I have a suggestion. To switch openssl to be 3.0.0 and create openssl1 for 10 packages that doesn't support openssl 3, until they switch. @ras0219-msft @JackBoosY What do you say?

@talregev
Some (at least 5) of these ports already support OpenSSL 3 but aren't updated to the latest version. We should update those ports first.
Everyone can have a look at #22878 (comment) and may update them.