Hi Jonathan, > On 19. Jul 2024, at 16:28, Jonathan Wakely <jwak...@redhat.com> wrote: > > On Fri, 19 Jul 2024 at 15:21, Jonathan Wakely <jwak...@redhat.com> wrote: >> >> Agreed. Boost Asio will use openssl engine if the user wants it to, >> and it will not use it if the user doesn't want it to. So Boost Asio >> does *not* depend on openssl-engine. It leaves the decision up to the >> users of asio headers. >> >> We should not force all users of boost-devel to install a deprecated package. > > It seems like the problem is that openssl assumes you want to use > engines *unless* you explicitly define OPENSSL_NO_ENGINE. But the > default is to assume you want them. Which is a problem when the > headers and libs aren't installed by default. > > We can patch Boost.Asio like so: > > --- /usr/include/boost/asio/ssl/detail/openssl_types.hpp > 2024-06-07 01:00:00.000000000 +0100 > +++ /tmp/openssl_types.hpp 2024-07-19 15:25:40.110115742 +0100 > @@ -22,7 +22,7 @@ > #endif // defined(BOOST_ASIO_USE_WOLFSSL) > #include <openssl/conf.h> > #include <openssl/ssl.h> > -#if !defined(OPENSSL_NO_ENGINE) > +#if !defined(OPENSSL_NO_ENGINE) && __has_include(<openssl/engine.h>) > # include <openssl/engine.h> > #endif // !defined(OPENSSL_NO_ENGINE) > #include <openssl/dh.h> > > (and similarly in the other Asio ehaders that check OPENSSL_NO_ENGINE) > > This would mean that you can define OPENSSL_NO_ENGINE to disable > engines, but they're automatically disabled if you don't have the > header installed.
This has the problem of making this fail-silent. Let’s consider this from the point of view of a package maintainer that wants to continue supporting ENGINEs (e.g., because you want to support PKCS#11 tokens and cannot yet use the PKCS#11 provider, or want to use a different OpenSSL ENGINE that has not yet been ported to the new provider model). If Boost applies this patch, your package will silently stop supporting ENGINEs until you declare a new dependency. Even worse, the package will now build with engine support or without engine support depending on the build environment. If this is what we want, we could have just declared `OPENSSL_NO_ENGINE` in the OpenSSL headers. See also https://bugzilla.redhat.com/show_bug.cgi?id=2296114, which is about this problem and documents the situation nicely. I still plan on looking into how to improve this situation, possibly by scanning the entirety of Fedora rawhide for use of OpenSSL ENGINE symbols and mass-filing tickets for these packages telling them I’ve silently disabled ENGINE support and they need to add a pre-processor define if they want them back, along with a change that defines OPENSSL_NO_ENGINE by default in the OpenSSL headers. > Even better would be for openssl/conf.h to do it: > > --- /usr/include/openssl/conf.h 2023-08-31 01:00:00.000000000 +0100 > +++ /tmp/conf.h 2024-07-19 15:27:57.513979007 +0100 > @@ -31,6 +31,10 @@ > # include <stdio.h> > # endif > > +#if ! __has_include(<openssl/engine.h>) > +# define OPENSSL_NO_ENGINE > +#endif > + > #ifdef __cplusplus > extern "C" { > #endif That’s one potential way, thanks for the patch – however, it has the same fail-silent problem. -- Clemens Lang RHEL Crypto Team Red Hat -- _______________________________________________ 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
