Hi Zbigniew! On Tue, Apr 2, 2024 at 1:15 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote:
> 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. > Thanks. In the period between the proposal was written and published the TPM2 provider has landed in Fedora. PKCS#11 provider is already here for a while. Should I update the Wiki page to adjust this point? > 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. > It's our goal - to eliminate the engine dependency. While a package can be built, it gets lower priority. > == 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. > I want to encourage the ecosystem to move to a viable target. > > 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. > I agree. > == 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. > Thanks! I like this idea and can update the Wiki page accordingly. -- Dmitry Belyavskiy
-- _______________________________________________ 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
