On Mon, Feb 24, 2025 at 05:53:46PM +0000, Aoife Moloney via devel-announce wrote: > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoBuildEngine > Discussion thread - > https://discussion.fedoraproject.org/t/f43-change-proposal-disabling-support-of-building-openssl-engines-system-wide/145922 > > 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. > > > == Summary == > > We disable support of building engines in OpenSSL and remove the > deprecated openssl-devel-engine subpackage. > > == Owner == > > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]] > * Email: dbely...@redhat.com > > > > == 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.
When a host is in FIPS mode, presumably openssl should already automatically disable all functionality that isn't FIPS compatible. Given that the symbols are intended to remain present in the ABI it doesn't seem like this change would have any impact on FIPS compatibility of openssl itself either way. Any FIPS issues have to be solved in apps consuming OpenSSL, changing their code to stop using the engine API, which can be done regardless of this change. > 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 Is this proposed dummy engine.h a Fedora downstream invention or something upstream does when engines are disabled ? Providing a dummy engine.h that does not actually contain any of the definitions that engine.h is supposed to provide feels like the kind of thing we should not do downstream only. It is liable to break any configure time checks that look for engine.h as a witness for being able to build engine support. > == 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 the engine. So we reduce the maintenance > burden and potentially attack surface. Below it is said that the symbols remain present in the library, so the attack surface remains unchanged AFAICS. Assuming it is intended to keep the symbols functional, the maint burden doesn't seem appreciably different either. Removing the engine support in Fedora, prior to upstream removing it, seems likely to increase the maint burden for others, by creating a Fedora-only compatibility problem for people wanting to build code that references the engine functionality. > == How To Test == > > Applications using OpenSSL ENGINE API can't be built. > ENGINE API is still exported by libcrypto. > With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
