Remove support for custom EVP_CIPHERs
Custom cipher methods are considered legacy and have been deprecated since 3.0. With the removal of ENGINEs they become a lot less useful and add significant complexity to the code. We should therefore remove them in 4.0.
I am proposing in the PR to simply delete the relevant API functions without providing stubs. Unlike with many of the ENGINE functions where applications could fallback to do something sensible if an ENGINE is not available, this isn't really the case with custom EVP_CIPHERs which are mostly useful for ENGINE authors (as opposed to ENGINE users).
Temporarily this is targetting the engineremoval branch because it is built on the commits there. But I don't expect this PR to land until after that branch has been merged to master (so I will retarget the PR at that point). Also, I have not done anything about the migration guide or removed API man page. That is pending #29220. So for these reasons I am making this PR a draft for now.
FYI @vavroch2010
I believe that this removal makes a whole bunch more code unreachable in the built-in EVP_CIPHERs. But that is left for subsequent PRs to clean up.
I'll save approval until after the re-targeting, but it looks good to me.
Now that the engine removal branch got merged to master, I have rebased this to target master. Still in draft because its still pending #29220, and then I need to make some updates to the migration guide etc.
Do we need also removing the similar API for! EVP_MD or it's already removed?
Do we need also removing the similar API for! EVP_MD or it's already removed?
Yes we do. And pkey methods and asn1 methods. But those are for later.
I am proposing in the PR to simply delete the relevant API functions without providing stubs. Unlike with many of the ENGINE functions where applications could fallback to do something sensible if an ENGINE is not available, this isn't really the case with custom EVP_CIPHERs which are mostly useful for ENGINE authors (as opposed to ENGINE users).
Many of the engine functions for which we have stubs are also useful only for ENGINE authors. And you can implement a cipher/md/pkey/asn1 method without actually implementing a full engine. However I agree that adding stubs for these functions is even more dangerous than adding stubs for engine calls as this can result in a completely broken functionality of an application if it depends on a custom method.
Force pushed to resolve reformatting conflicts with master
This is now ready for review.
LGTM overall. I wonder whether commands like
man SOME_REMOVED_APIwould work - will it be automatically redirected to ossl-removed-api.pod?
Yes, that is what is expected.
All of your comments @t8m should be addressed. Fixing them led me to discover some further sections of the code which were dead and hence I've removed those too.
Please take another look.
This pull request is ready to merge
please don't forget to add a mention to the changelog
We can do that later. We will review the CHANGES before the alpha release anyway.
Merged to the master branch. Thank you.