Deprecate Openssl engine support
Summary
We disable building the packages using ENGINE API in OpenSSL without breaking ABI.
Owner
- Name: Dmitry Belyavskiy
- Email: dbelyavs@redhat.com
Current status
- Targeted release: Fedora Linux 41
- Last updated: 2024-10-02
- Announced
- Discussion Thread
- FESCo issue: #3193
- Tracker bug: #2276420
- Release notes tracker: #105
Detailed Description
We are going to deprecate OpenSSL engine support. Engines are not FIPS compatible and corresponding API is deprecated since OpenSSL 3.0. The engine functionality we are aware of (PKCS#11, TPM) is already covered by providers.
We don't plan to remove the API from libcrypto.so. We are going to prevent creating the new packages dependent on OpenSSL ENGINE API and remove ENGINE dependencies from the existing packages.
During discussion of the previous proposal - to completely remove the ENGINE API - there were many relevant arguments why it shouldn't be done. We agree with them but still want to deprecate the ENGINE support to simplify removing it in the earliest release when it's feasible.
Current plan is splitting the openssl-devel package to 2 packages, the one containing all the .h files except engine.h and the one providing the engine.h file, e.g. openssl-engine-devel, mark it as Provides: deprecated(). Existing packages which need the engine headers can adjust to use the new header and new packages are prevented by the Packaging Guidelines from adding a dependency on deprecated packages.
Thanks to Zbigniew Jędrzejewski-Szmek for this idea
Feedback
Benefit to Fedora
We get rid of deprecated functionality and enforce using up-to-date API. Engine support is deprecated in OpenSSL upstream, and after provider migration caused some deficiencies with engine support. No new features will be added to engine. So we reduce maintenance burden and potentially attack surface.
It follows approach planned for CentOS 10.
Scope
- Proposal owners: maintainers of packages enumerated here: https://clang.fedorapeople.org/c10s-engine-users/ plus probably owners of some Fedora-only packages
For most of the packages the maintainers will just have to rebuild their packages after the OpenSSL change lands in compose. For several packages some patches should be implemented to prevent compilation errors.
- Other developers: -
- Release engineering: #Releng issue number
This change probably requires mass-rebuild.
- Policies and guidelines: We need reject/modify packages providing OpenSSL engines
- Trademark approval: N/A (not needed for this Change)
- Alignment with Community Initiatives:
Upgrade/compatibility impact
None. Users will be encouraged to switch their configurations to use providers instead but existing engines will continue working.
How To Test
OpenSSL libcrypto.so exports the same ENGINE_* symbols as for f40. Applications relying on the ENGINE API can't be built but still work.
User Experience
Users will be encouraged to reconfigure systems to providers if they use engines. No other changes are expected.
Dependencies
In theory, all OpenSSL-dependent packages. In practice, only those that explicitly use ENGINE api.
Contingency Plan
None needed as the build issues can be resolved by adding a BuildRequires: openssl-engine-devel
- Contingency mechanism: (What to do? Who will do it?) rebuild OpenSSL and dependent packages
- Contingency deadline: beta freeze?
- Blocks release? Yes
Documentation
TBD
Release Notes
TBD