On Tue, Apr 02, 2024 at 10:45:32AM +0100, Aoife Moloney wrote: > == Summary == > We disable building the packages using ENGINE API in OpenSSL without > breaking ABI. "Without breaking ABI" is a improvement. Everything else — not so much. > == 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. This doesn't really answer the problems that were raised in the previous round of discussion. Even if the plan is that some functionality will be provided "soon", dropping engine support _right now_ will cause problems for developers and for users: first the providers need to become available and have the complete feature set, then the upstreams have add the relevant provider code and document things so that users know how to adapt, and then we need to integrate all of that downstream in packaging. If we start be ripping out the engine functionality, we'll have a window, of unpredictable length, where the functionality will not be available. This is bad for users, but also breaks the promise that Fedora is the best environment for upstream development. > 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. IIUC, this is implemented by dropping the header files. This is not acceptable: it would break package rebuilds. > == 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. Such things are always a tradeoff. The benefit of removing the deprecated code obviously reduced the maintanance burder a bit. But is is really that much? OTOH, it disables features that are being used or developed in a bunch of important projects. It seems very premature to take this step for F41, i.e. sometime within the next two—three months. It seems that the ecosystem isn't ready. The tradeoff for CentOS 10 is different: the first release is still a while away and most people will not jump onto the 10.0 release anyway. By the time CentOS is used in anger, the ecosystem might be ready. This is one of the cases where using Fedora as a pre-release for CentOS as a pre-release for RHEL is detrimental to Fedora. > == 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. That's incompatible with package rebuilds… An acceptable approach would be to split out the headers to a separate -devel 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. Zbyszek -- _______________________________________________ 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
