F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)

Project Discussion Change Proposals
,
1

Deprecate Openssl engine support

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

We disable building the packages using ENGINE API in OpenSSL without breaking ABI.

:link: Owner

:link: 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 either covered by providers or will be covered soon.

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.

:link: Feedback

:link: 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.

:link: Scope

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.

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:

:link: Upgrade/compatibility impact

None. Users will be encouraged to switch their configurations to use providers instead but existing engines will continue working.

:link: 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.

:link: User Experience

Users will be encouraged to reconfigure systems to providers if they use engines. No other changes are expected.

:link: Dependencies

In theory, all OpenSSL-dependent packages. In practice, only those that explicitly use ENGINE api.

:link: Contingency Plan

Returning the engine header file to allow old applications to be built.

  • Contingency mechanism: (What to do? Who will do it?) rebuild OpenSSL and dependent packages
  • Contingency deadline: beta freeze?
  • Blocks release? Yes

:link: Documentation

TBD

:link: Release Notes

TBD

2 Likes
2

This change proposal has now been submitted to FESCo with ticket #3193 for voting.

To find out more, please visit our Changes Policy documentation.

1 Like
3
How do you feel about the proposal as written?
  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

4

As stated in the previous discussion, STRONGLY OPPOSE unless the headers are agreed to be shipped for users who are using non-Fedora shipped engines. The headers can be shipped in another package (requiring a BR change), but they MUST be shipped with Fedora, and not as a maybe contingency at a later time. I had thought the proper had agreed to that, but it appears that this has gone backwards.

1 Like
5

Engine header would be separated to a different package that is not going to be removed from Fedora now. The package would be marked as deprecated.

Could you please point me which wording should be adjusted?

6

Well, I think the proposal should be retracted, as the headers are already marked deprecated (so warnings at compile), and those that are still using engines should certainly be aware of the issue.

But if you wish, here are the proposed changes:

Title: Further Deprecate OpenSSL engine headers

Summary: We further discourage use of OpenSSL engine support

Detailed Description: We are going to further deprecate the OpenSSL engine support by moving the headers to separate sub-package. We will not change the OpenSSL API (engine support will be maintained). We will not remove engine support until OpenSSL 4.0 (when it is expected to be removed upstream). New openssl engine providers will not be accepted into Fedora.

Benefit to Fedora: More strongly remind users of engines that future versions of OpenSSL will not support engines (this is a very weak benefit, but it is the best I can do).

Scope: The engine headers will be moved to another sub-package. Users of engine support will need to change their BRs to specify the addition sub-package (either by package name, or a new (to be created) pkgconfig specification (BR: pkgconfig(openssl-engine)?).

Upgrade/compatibility impact: Minimal/None. The proposal owners will run a mass build against all existing packages which have a BR on openssl to test if any existing packages will FTBFS and inform the impacted packagers [[the mass-prebuild tool should be useful here, although there are many other possible tooling available to the proposal owners]].

How to test: … Applications relying in the engine API CAN still be built, but are further discouraged. Changes to BR if one is using engine support will be required.

Contingency plan: [[as the engine headers WILL be available, old applications CAN be built, there seems to not need to be a serious contingency needed]]

7

Yes, they are. But it doesn’t imply any obligation. My proposal is more strict - moving headers to a separate package implies that no new engine-dependent packages will be added to Fedora.

And, last but not least, I still would like to enforce most of the packages that currently use engine API just be rebuilt without it. In most cases it will not do any negative effect.

8

This change has been accepted by FESCo for Fedora Linux 41. A full list of approved changes to date can be found on the Change Set Page.

To find out more about how our changes policy works, please visit our docs site.

9

I can say that this change breaks the functionality of the boost::asio::ssl library.

In file included from /usr/include/boost/asio/ssl/context_base.hpp:19,
                 from /usr/include/boost/asio/ssl/context.hpp:23,
                 from /usr/include/boost/asio/ssl.hpp:18,
                 from ... :
/usr/include/boost/asio/ssl/detail/openssl_types.hpp:26:11: fatal error: openssl/engine.h: No such file or directory
   26 | # include <openssl/engine.h>
      |           ^~~~~~~~~~~~~~~~~~
compilation terminated.

Also, ELN builds fails, and there is no openssl-devel-engine package. Example: https://download.copr.fedorainfracloud.org/results/supervillain/i2pd/fedora-eln-x86_64/07767561-i2pd-git/builder-live.log.gz

10

Boost’s packaging needs to be updated, I reckon.

As for ELN - since it will reflect what goes into CentOS in a few years (then maintained for a decade plus!) it’s likely this won’t be reintroduced.

When we have had issues (eg when libxcrypt-compat was dropped) the solution was to package it as an EPEL only package, and add it to one of the eln-extras workloads (those are for packages that will end up in EPEL instead of RHEL/CentOS)

11

I’m getting the following error when compiling librdkafka on Fedora 41:

In file included from rdkafka_int.h:90,
                 from rdkafka.c:42:
rdkafka_conf.h:36:10: fatal error: openssl/engine.h: No such file or directory
   36 | #include <openssl/engine.h>
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.

How to install openssl/engine.h header file (there’s no openssl-devel-engine package)?
Also I couldn’t find any information on this when googling – do maintainers of The Apache Kafka C/C++ library know about this problem?

12

As far as I can see, openssl-devel-engine exists, contains the header, and is installable from the default repository:

❯ dnf provides /usr/include/openssl/engine.h
Updating and loading repositories:
Repositories loaded.
openssl-devel-engine-1:3.2.2-9.fc41.i686 : Files for development of applications which will use OpenSSL and use deprecated ENGINE API.
Repo         : fedora
Matched From :
Filename     : /usr/include/openssl/engine.h

openssl-devel-engine-1:3.2.2-9.fc41.x86_64 : Files for development of applications which will use OpenSSL and use deprecated ENGINE API.
Repo         : fedora
Matched From :
Filename     : /usr/include/openssl/engine.h

What happens when you try and install it?

Further troubleshooting probably belongs in a new topic rather than a reply to this change proposal though, given that the proposal is already accepted and implemented.

1 Like
13

Thanks, my fault as I was trying openssl-engine-devel name :smiley:

1 Like