F43 change Proposal: Disabling support of building OpenSSL engines (system-wide)

Project Discussion Change Proposals
,
1

Disabling support of building OpenSSL engines

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 support of building engines in OpenSSL and remove the deprecated openssl-devel-engine subpackage.

:link: Owner

:link: Detailed Description

We are going to build OpenSSL without 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 covered by providers. The package necessary to build engines (openssl-devel-engine) is already declared as deprecated and will be removed. For the applications that still unconditionally refer to openssl/engine.h we will provide a dummy engine.h file

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

:link: Scope

  • Proposal owners: maintainers of packages relying to openssl engine funcionality

  • Other developers:

  • Release engineering: #Releng issue number

This change probably requires mass-rebuild.

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

OpenSSL engines will no longer be supported. Engines will not be supported in openssl configuration files (presumably silently ignored). Users will have to reconfigure systems to providers if they use engines.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? Y/N

:link: How To Test

Applications using OpenSSL ENGINE API can’t be built. ENGINE API is still exported by libcrypto.

:link: User Experience

Users will have 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

Reenable openssl-devel-engine package keeping it deprecated

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No

:link: Documentation

TBD

N/A (not a System Wide Change)

:link: Release Notes

TBD

Last edited by @amoloney 2025-02-24T17:57:00Z

Last edited by @amoloney 2025-02-24T17:57:00Z

2

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 give 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

This proposal (or equivalent ones) seems to keep coming back, even though it has been rejected previously. Yes, OpenSSL 4.0 (whenever it is released) will no longer support engines. When the last OpenSSL 3.0 compat package is removed from the distribution is the time to end support of engines. It is unproductive to continue to reintroduce the same proposal without addressing all the previous reasons it was rejected.

5

I’m sorry, you are not correct. This proposal is not equivalent to the ones that were already rejected. It’s a next step in a step-by-step engines elimination.

6

It’s a completely irrelevant example. It does not use openssl otherwise than command line utility (you can search for engine and openssl in the code) and of course, openssl command line utils provide support for providers

7

You are right, I was confused by the pesign manpage which only mentions signing with an openssl engine.

Do note that sbsigntools, another popular tool in this space does not yet support providers either. I did implement systemd-sbsign in systemd 257 which does support providers and updated all other tools in systemd that do signing to support providers in systemd 257 as well.

8

I am surprised by how little of the proposal is dedicated to the impact on packages that still require the Engine API to build. The proposal seems to assume that package maintainers will just find a way to deal with the removal, but in cases where engine support is an intentional part of the upstream design and is not easily removable by something like a build conditional, and where upstreams have not yet ported to providers, Fedora package maintainers are likely to find themselves without any acceptable options.

Porting nontrivial upstream code from engines to providers requires a high level of familiarity with both OpenSSL and upstream code, and most package maintainers won’t be prepared to attempt it. To make things worse, patches would involve potentially security-critical code and might be difficult to test, requiring things like hardware tokens.

Here’s a best-effort list of packages that still require the engine API:

$ fedrq wr -s openssl-devel-engine -F name
R-openssl
bind
boinc-client
cpprest
curl
dotnet8.0
erlang
fsverity-utils
fuse-encfs
gambas3
gdal
grpc
hitch
httping
kea
libcoap
minizip-ng
mosquitto
mstflint
myproxy
mysql8.0
nbdkit
nextcloud-client
nrpe
ocspd
openssl-gost-engine
openssl-pkcs11
osslsigncode
pdns
pdns-recursor
poedit
proxygen
pypy
pypy3.10
pypy3.9
qbittorrent
rb_libtorrent
root
s2n-tls
sbsigntools
sendmail
sslsplit
strongswan
stunnel
systemd
tinc
tor
tpm2-tss-engine
trafficserver
trojan
uboot-tools
ufdbGuard
uperf
websocketpp
wesnoth
workflow
wpa_supplicant
xca
xmms2
yadifa
znc

This is a lot of packages, and some of them are very important. With very few upstreams moving to remove the engine API, and with the obstacles to downstream workarounds I already described, it seems like the expected result of removing engine API support right now could best be described as carnage. Is there any plan at all to make the impact of this change more palatable?

2 Likes
9

The ones in RHEL (systemd, stunnel, mysql, curl, bind, wpa_supplicant, some more from the list) are already ported to providers. tpm2-tss-engine should be replaced by tpm2-openssl. gost-engine is not maintained upstream now (I had to abandon it and I’m not aware of any new upstream maintainer).

We have to move to providers. In most case it doesn’t require any code changes, speaking frankly. Also a lot of applications “using” engines don’t really use them.

10

Yet, the proposal still misses to highlight the impact on dependent packages and doesn’t say if the submitters are willing to help fixing them.
As it is, it seems that the proposal is “we will remove openssl-devel-engine and is up to other maintainers fix their packages to work without it”, which is clearly a no-go IMO.

11

Dear Mattia
I am willing to provide some assistance in fixing the engine issues.

OTOH when we switch to OpenSSL 4, the engine support will be absent, the openssl-engine-devel package will be definitely removed, and the compat package will not provide it. The time frame for it is no later then F44. So the time to get rid of engine compilation dependency is now.

12

Yes, I understand that. But I think a better approach would be to start adding openssl-devel-engine to deprecated packages and work to move dependent packages away from it using the F42 and F43 development time frame to reach a state where in F44 all packages (or just a few) still require it.

I do understand that OpenSSL 4 removes support to engines, but since OpenSSL 3 still support it, it’s useless to break all packages until we really move to 4. A package deprecation will mark the urgency to move away from it without blowing everything up.

13

openssl-devel-engine is already deprecated

14

I mean Deprecating Packages :: Fedora Docs
Looking at the openssl spec file, I don’t see the subpackage is marked as deprecated.

15

Thank you very much. The deprecation of this package was approved but not marked properly, I will restore it.

16

Why not? You have not provided any statement as to why it cannot be provide in the OpenSSL 3.x compat package, just as it is provided now. Deprecated does not mean removed, but it means no additional uses should happen (and we should not see new uses being approved, while existing ones should be able to continue).

The original removal of engine support was rejected by FESCo as it was proposed until the engine headers were made available. As we know, that modification was done, and the proposal accepted with the header support. The reasoning for keeping the engine support for OpenSSL 3.0 by FESCo has not substantially changed. Trying again and again until one gets to a yes because people do not remember history does not seem to be a productive use of the communities resources.

What I can think of as a productive use of time would be submitting PRs to all upstreams to remove the current engine usage. You mentioned that RHEL has removed engine usage in some cases. Are all those patches upstream and in Fedora? If not, why not? Since you have offered assistance to get rid of engine usage, I am sure those upstreams will welcome your efforts.

17

@gtb I think it’s a misunderstanding

AFAIK, we normally don’t provide headers with the compat package. And they will strongly interfere with the headers from the main package if provided

I agree about providing PRs but I think this should be done by the maintainers of the packages. I can provide some feedback/answer questions/etc but I will not submit any PRs to the upstreams I have never heard before

18

Compat packages in Fedora are effectively useless without headers, because anything that links them would promptly fail to build from source. That’s never something we want to happen on purpose in Fedora, especially with no clear resolution in sight.

Besides not being able to ship bug fixes or security patches, a package that fails to build from source can start to fail to install at any time, especially in Rawhide, where one of its dependencies may ship an ABI-incompatible update (properly coordinated or otherwise). Once that happens, the package is destined for inevitable retirement unless it can somehow fix the FTBFS.

It’s acceptable and reasonably common for C and C++ compat packages to have -devel subpackages that conflict with the base version -devel subpackages, as long as the library packages don’t conflict; see Conflicts Guidelines :: Fedora Docs.

1 Like
19

Agreed, as anyone with an actual long term clue
about packaging knows. Not everyone has actual
clue, which, apparently, is why this confusion needs
to be addressed again and again,

20

Thanks, that really opens some way forward but I still strongly recommend moving packages to provider API

21

Right now, effort should be directed into moving those dependents (listed in an earlier comment) away from openssl-devel-engine and away from the engines themselves. In some cases, no further code changes will be needed now that OPENSSL_NO_ENGINE is automatically defined if openssl-devel-engine is absent (which was not the case when that was first split out from openssl-devel), but in others code changes (some straightforward, some extensive) will be needed. But openssl-devel-engine unfortunately cannot simply be disabled without that work taking place first.

1 Like