Removing or keeping some engine functions in 4.0

I'm not in favour of removing these ones. However, they are not related to the question being asked.

Nonetheless, would making these calls return NULL be better or worse than removing them? This is the fundamental question being asked about the engine functions.

I don't know the answer at this stage because I don't know how widely those functions are used, or in what context they are used. We should do some work to try and figure that out (and since we are talking about several functions here, the answer might be different for different ones). So, IMO, we should be reverting the change that completely removed them and then do that work. That could result in their removal again - and I would be fine with that. My argument is that their removal now at this point in the development cycle is premature because we haven't done the necessary pre-work.

@Matt Caswell I disagree. The work (the removal) is done on a feature branch. We can re-add the stubs there any time if we really decide to do so. Having the feature branch with the functions removed allows for better evaluation of what can possibly break if these function stay removed in 4.0 version. We can also demonstrate how the 4.0 will look like if the decision will be to remove them.

Of course before merging the feature branch, we need to do the final decision and have or have not the stubs according to that decision, but there is a plenty of other work to be done before that can happen.

I have an impression that the feature branch has a lot of commits waiting to be merged that should remove most of the ENGINE API. Am I correct?

BTW, I note that 3 of the functions that this PR restores are not even deprecated!!! So they should never have been removed in the first place without some form of exception.

@Matt Caswell, of course, dropping functions that weren't deprecated to start with is wrong.

I think we could make an exception because of being quite pointless to keep these functions but I agree that it is a valid argument

@Todd Short I think your response better matches "No" (not reintroduce the engine functions)

@Tim Hudson I think your response better matches "No" (not reintroduce the engine functions)

@Dmitry Belyavsky, Tim's response matches "yes", his text says "remove the implementation", but not the interface.

@Tim Hudson I can agree with this view, yet I would point out that this perspective is definitely biased in favor of existing codebases rather than being friendly to new developers and new applications.

Putting the hat of any of my students when they first start dealing with OpenSSL , the API and way of using functions is difficult to understand or justify, until they take a deep dive in the history of how OpenSSL and specific APIs emerged. It might be fine when there is someone that already went through that and can guide them with a big dose of handholding, but putting our main focus on trying to please mainly the existing codebases and veteran developers at the expense of clean and concise APIs might not be the most sustainable choice for the long-term (once veteran developers retire and the new maintainers of those applications start advocating for replacing OpenSSL with something easier to use and understand).

Just to provide a bit of context, looking at my local fedora 42 system, the following libraries and applications there reference symbols that have an ENGINE prefix:

./qt6/plugins/digikam/marble/CachePlugin.so

./qt6/plugins/digikam/marble/GpsbabelPlugin.so

./qt6/plugins/digikam/marble/GpxPlugin.so

./qt6/plugins/digikam/marble/JsonPlugin.so

./qt6/plugins/digikam/marble/KmlPlugin.so

./qt6/plugins/digikam/marble/NominatimReverseGeocodingPlugin.so

./qt6/plugins/digikam/marble/Pn2Plugin.so

./qt6/plugins/digikam/marble/PntPlugin.so

./systemd/libsystemd-shared-257.9-2.fc42.so

./strongswan/plugins/libstrongswan-openssl.so

./python3.13/site-packages/grpc/_cython/cygrpc.cpython-313-x86_64-linux-gnu.so

./libpkcs11.so

./libcurl.so

./eapol_test

./wpa_supplicant

./mosquitto

This is by no means a full accounting (need to download and examine all packages from the fedora core repo, but I'd like to make sure that there is a better understanding of the impact of the removal of these apis.

I'm don't think digikam is something that we need to worry about too much, but systemd, cypython, libpkcs11, libcurl, and the various impacted applications probably need to be informed about this to ensure distributions don't encounter unexpected loss of functionality.

That said, I'm in favor of removing these APIs. Barring further discoveries (which I will post here), I think this is an addressable list in the 4.0 time frame (though I'm not the one doing that work, so my opinion matters less on that account.

@Neil Horman we have already dealt with some of these packages in Red Hat, and for Fedora I expect that we would inevitable keep openssl3 package for those packages that rely on ENGINE API

No argument, as I noted above, I'm in favor of removing these APIs, I just want to be sure that we have a clear understanding of the impact of doing so, and the downstream work effort we are placing on dependent packages.