API Deprecation Announcement for OpenSSL4.0

I strongly support an idea having this announcement.

I think we can deprecate ENGINE API as a whole: OpenSSL has intentionally deprecated it, and various forks have dropped it

From discussions earlier this year between the Foundation and Corporation, I believe we are all on the same page about Engine support and 4.0 would be an ideal time to remove that API. As far as I know, the GOST engine would be the only causality and there is time to convert it to a provider if there is interest.

Announcing the change as early as possible is a great idea. I'll raise it internally.

Thanks Jon! I think that's great and appreciate it very much. If other deprecated API's are being removed (not just engines) could we mention that as well? Thanks for your consideration and help.

As for possibilities for removals - basically anything that is deprecated in 3.5 can be removed in 4.0. However we do NOT have to remove everything. Here are some possible subsets:

• only ENGINE API (except for the ENGINE opaque type) - this does not bring much in terms of simplification of the code base. However we can at least not care about any breakage of engines in 4.0

• above + all EVP_PKEY_METH related stuff - this fairly simplifies EVP_PKEY handling code

• above + all EVP*_METH related stuff - simplification also for EVP_CIPHER and EVP_MD handling

• above + EVP_PKEY_ASN1 method stuff - this would require an exception as we are going to deprecate it in 3.6 so technically we would be breaking our policy if we would remove it 4.0, however this would get rid of almost all legacy handling in EVP

• above + RSA/EC/DSA/DH low level types and related functions - probably too radical for 4.0 although it would further simplify things

• symmetric low level types and functions - this is again probably too radical for 4.0 and would not bring much benefit apart from cleaning up our public API. Maybe we could remove just some particularly nasty and insecure crypto functions such as single DES low-level support or similar.

We would like to know opinions of the communities on the above.

I would say it makes sense to check what API has already been removed from OpenSSL forks. I'm pretty sure the 1st 4 points from Tomas's list are a subject to removal.

Speaking from the large business perspective I don't see concern with removing ENGINE API. I do worry about stable APIs and replacements for everything else. I understand the EVP methods are replaced by provider calls, but what are the alternatives suggested for the low level functions.

It would be a good idea to see how much of the open source community has already adopted the provider calls, and check again as the 4.0 timeline closes to gauge how ready the world is getting. I wouldn't be surprised if projects move to other OpenSSL forks so they don't need to migrated. Similar to @Dmitry Belyavsky point on what forks have already removed.

Strictly from a Cisco point of view, we see heavy ENGINE usage across the portfolio. All must be converted to provider of course :). My concern is "when" these deprecated API's are going away. Is it phased? Is it ENGINES only? Is it EVP or low-levels? All of the above? Across a large business with a huge portfolio and corresponding engineering teams, this info would be immensely helpful for planning and execution.

Should we set up a meeting to discuss the API removal options? Please note all the APIs (except for EVP_PKEY_ASN1 method API) were already deprecated (with the intention of future removal) as of OpenSSL 3.0 - that is almost 4 years ago now. So we are not talking about deprecation but a real removal of some of these deprecated APIs within the 4.0 release.

But of course we do not have to remove everything that was deprecated. We can keep some of these deprecated functions if we decide it is not a major maintenance burden and applications are still using them. In particular at least some of the low level crypto functions IMO do not incur major maintenance costs and we might not want to remove them in 4.0.

Correct. It's more about removal of already announced deprecated API's and when they will depart than the deprecation itself. Although that is an important topic. Thanks Tomas!