On Wed, Mar 20, 2024 at 02:35:21PM +0100, Dmitry Belyavskiy wrote: > Dear Daniel, > > On Wed, Mar 20, 2024 at 1:44 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> > wrote: > > > On Fri, Mar 08, 2024 at 08:37:19PM +0000, Aoife Moloney wrote: > > > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine > > > > > > 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 engines in OpenSSL > > > > > > == Owner == > > > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]] > > > * Email: dbelyavs@xxxxxxxxxx > > > > > > == 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 either > > > covered by providers or will be covered soon. > > > > "will be covered soon" > > > > ... so lets wait until that work is actually complete before > > removing this from openssl, otherwise there's a window of > > brokenness in Fedora where the old feature is removed and > > the new feature is not ready. > > > > I am not going to land this change until the tpm2 provider is landed in > Fedora. Lets explicitly note that as a blocking / pre-requisite dependency for landing this change then. > > > == 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. > > > > What is upstream's intention with the 'engine' feature deprecation ? > > > > Are they going actively remove this functionality after some > > period of deprecation ? If so what's upstream timeframe, and > > should Fedora just wait for that, rather than jumping the > > gun ? > > > > As I understand, upstream is going to remove engines but it wouldn't happen > before OpenSSL 4.0 That makes sense, as it solves the ELF ABI / SONAME change issue with removing the APIs. > I don't think Fedora should wait for that. We definitely want to land > no-engine in RHEL10 so Fedora should be ready for that. Fedora shouldn't neccessarily be rushed into something just because RHEL wants to do it prematurely due to RHEL's long lifecycle. > > > == 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. > > > > > > > > > == How To Test == > > > OpenSSL libcrypto.so doesn't export any ENGINE_* symbols (~120 lines). > > > Application is normally built. > > > > Removing symbols is an ABI break, so would imply the need for > > an SONAME version bump. This is not normally something that > > downstreams should ever touch though - it is an upstream > > decision when to bump their SONAME version. > > > > Should we not preserve the ENGINE_* symbols, but turn > > their impl into either a no-op, or reporting a runtime > > error, as appropriate for each API. > > > > All 100+ symbols? I don't think providing non-working stubs would be a good > idea... Intentionally forking the upstream ABI is worse IMHO. Consider you've built your own app on Fedora 39 that uses these symbols, and now upgrade to F40. RPM will consider the dependency still satisfied, as the SONAME hasn't changed on libcrypto. The app throws linker errors at some point due to the missing symbols. Another alternative is to continue providing fully functional engine symbols, but remove the header files so in practice you can't compile something new that uses it. This is still forking the API, but at least has not forked the ELF ABI, so the upgrade doesn't explode. 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
