Hi Zbigniew!
On Tue, Apr 2, 2024 at 1:15 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> 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@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
