Dear Daniel,
On Wed, Mar 20, 2024 at 3:06 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
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.
Fair point, will do.
> > 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.
I agree that this option is on the table.
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
