Removing or keeping some engine functions in 4.0
PR https://github.com/openssl/openssl/pull/28617 reintroduces as dummy several ENGINE functions.
I don't think we need to keep these functions, as 4.0 removes all the other engine support.
Poll Created Sun 21 Sep 2025 2:11PM
Do we need reintroducing ENGINE related functions (setters/getters) as dummy? Closed Wed 24 Sep 2025 2:00PM
Results
Results | Option | % of points | Voters | |||
---|---|---|---|---|---|---|
|
No | 75 | 9 |
![]() ![]() ![]() ![]() ![]() ![]() |
||
|
Yes | 25 | 3 |
![]() ![]() ![]() |
||
Undecided | 0 | 12 |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
12 of 24 votes cast (50% participation)

Nicola Tuveri Sun 21 Sep 2025 2:11PM
I understand the will to not break the build process of existing applications. But for all the functions that had already been marked as deprecated I believe 4.0 is the right time to make a “breaking” change.
I don’t think a runtime failure is more desirable than a build time failure. Actually a build time failure seem more useful for maintainers to quickly get to all the places where the ENGINE vestigial bits can be removed.

Paul Dale Sun 21 Sep 2025 2:11PM
A build break is far better than a run time error here. Especially is the error return isn't checked and application behaviour changes without warning/notice.

Tomas Mraz Sun 21 Sep 2025 2:11PM
No function that does NOT have any meaning without the engine support should be restored.

Matt Caswell Sun 21 Sep 2025 2:11PM
IMO removal of these functions was premature. Removal of functions has a significant impact on downstream users. The more functions you remove the harder it is for them to upgrade which means that they don't. They stick on the old version for as long as possible. This is bad for them (security/features etc) and bad for us (we want as many people as possible on the latest versions). Note: I am arguing for more time to properly consider removal. That might still lead to removal of these functions.

Matt Caswell Mon 22 Sep 2025 1:30PM
Do we? Which ones?
Dmitry Belyavsky Mon 22 Sep 2025 2:04PM
Don't we? If not, I think we should...

Matt Caswell Mon 22 Sep 2025 3:48PM
I think we need to carefully consider all deprecated functions and really consider what the impact of removing them is. How widely are they used? What is the impact on our user community of removing them and what is the benefit to us of having the function removed. Take for example the `TLSv1_2_*method()` functions. They are deprecated. My guess is the impact of removing those functions will be very widespread and disruptive to the community. The fix is of course easy once you know how. But nonetheless I expect a significant number of applications will simply not upgrade as a result. This is a BAD outcome for everyone involved. I am NOT arguing that we shouldn't remove stuff - but I am arguing that we need to carefully consider each function and weigh up the benefits of removal vs the impact on the community. The particular functions in the PR concerned were removed without this thinking having been done. So they should go back until we can properly assess them.
Dmitry Belyavsky Mon 22 Sep 2025 3:52PM
I agree - but the engine-related API should definitely be gone
Dmitry Belyavsky · Mon 22 Sep 2025 10:48AM
But we remove a lot of more widely used functions in 4.0, why do you consider these ones specific?