On Fri, 19 Jul 2024 at 15:52, Clemens Lang <cllang@xxxxxxxxxx> wrote: > > Hi Jonathan, > > > On 19. Jul 2024, at 16:28, Jonathan Wakely <jwakely@xxxxxxxxxx> wrote: > > > > On Fri, 19 Jul 2024 at 15:21, Jonathan Wakely <jwakely@xxxxxxxxxx> 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. It means that packages which want to use engines have to explicitly enable them, or they silently get no engines. If they really require engines to work, then will it be silent? A program that calls e.g. ENGINE_cleanup(); will not fail silently if that symbol has been disabled due to an implicit OPENSSL_NO_ENGINE. It's possible to find all packages in F40 (before openssl-devel-engine was introduced) that depend on the ENGINE_cleanup symbol (or some other symbol if there's a better one to check for), which will tell us all the packages that were affected by this change. Then bugs can be filed and each package can decide whether to add BuildRequires: openssl-devel-engine to its spec or not. Once that's step is done, all existing packages will be correct: they either don't use engines, because they never needed them, or they opt-in to using them. Then there will be no silent failures. Anything that isn't using them is doing so intentionally, so not a "failure". For new packages that want to use engines, presumably somebody will check that engine support is enabled when testing the functionality of the new package. If they mess that up, that's a packaging bug and can be fixed. So I really do think the way to fix this is to default to OPENSSL_NO_ENGINE and simultaneously file bugs for all packages using ENGINE_cleanup and tell them to decide whether to BuildRequires: openssl-devel-engine. -- _______________________________________________ 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
