A recent commit from 5 days ago removes engine related files from this package, but does not define OPENSSL_NO_ENGINE in the include directory. This means that if a project depends on this definition to build in OpenSSL Engine functionality, it will fail to build. This is specific to the openssl-devel subpackage Given this example code: #ifndef OPENSSL_NO_ENGINE #include <openssl/engine.h> #endif Will fail to build with engine.h not being found Please tell me if I've gotten something wrong, I don't use Fedora, just discovered this bug and felt I should report it. Reproducible: Always Steps to Reproduce: Take a project that attempts to build with OpenSSL engine functionality on many platforms using the example code above Actual Results: Build will fail with engine.h not being found Expected Results: Build will succeed if OPENSSL_NO_ENGINE is defined
See https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/H3OOWA43BGEBTSM2GRBYDN3SLUTETFL5/ and thread for discussion. The issue here is that as the OpenSSL maintainers, we have two options if we want to deprecate OpenSSL ENGINEs: - silently set OPENSSL_NO_ENGINE, and require package maintainers to use a separate workaround to re-enable it if they notice and want to continue supporting ENGINEs in their packages - break the builds and require installing the openssl-devel-engine package, which provides all headers as they have been previously None of the options is great. If you're just a downstream user, installing openssl-devel-engine will fix the issue for you.
Thanks for the clarification! The project that I found the issue in has fixed it by installing openssl-devel-engine (https://github.com/SoftEtherVPN/SoftEtherVPN/pull/2022). It was very minor fix thankfully. After reading through the thread here's my (admittedly one sided) view. I still don't really understand the problem with defining OPENSSL_NO_ENGINE. It seems to me that it should be very simple: a package that does not have engine functionality should say that it does not have that functionality. If a package wants to continue using engines, can package maintainers not make it simply depend on openssl-devel-engine instead of openssl-devel? The maintainers who want to continue to use deprecated functionality should have to do the extra work, right? Here's the three situations I see: 1. A package has no engine functionality at all, and doesn't include engine.h - No problem here, this change didn't affect anything. 2. A package can build with or without engine functionality. This is what happened with our project. For this OPENSSL_NO_ENGINE needs to be defined, or openssl-devel-engine is installed. 3. A package NEEDS engine functionality. They must depend on openssl-devel-engine. The problem seems to be with situation two, but you mentioned that the problem with defining OPENSSL_NO_ENGINE is that "[requiring] package maintainers to use a separate workaround to re-enable it if they notice and want to continue supporting ENGINEs". Can a package maintainer in situation 3 or a package maintainer in situation 2 who wants to support engines not change their package's dependency on openssl?
Sorry, it seems like I totally missed the part where the problem is the SILENT failing of engine functionality. Although I still think it should be defined, the decision becomes a lot more understandable. My problem still is that as a downstream user, it took a LOT of time (>2hrs) to figure out that Fedora's openssl package doesn't define OPENSSL_NO_ENGINE. Even then only solution (other than modifying source code) is for the downstream user to install a deprecated package.
OK, so the good news is I found a pretty simple way to scan all dependents of `openssl-libs` (on x86_64 only for now) for use of ENGINE symbols. Essentially I used $ dnf repoquery --whatrequires openssl-libs $ dnf repoquery --whatrequires 'libcrypto.so.3()(64bit)' --whatrequires 'libcrypto.so.3(OpenSSL_3.0.0)(64bit)' --whatrequires 'libssl.so.3()(64bit)' --whatrequires 'libssl.so.3(OpenSSL_3.0.0)(64bit)' to compile the list of potentially affected packages, then downloaded them using $ dnf download $(cat packages) and analyzed them for the symbols they link against. With these results, I should be in a position to automate filing tickets against all users of OpenSSL ENGINEs in Fedora rawhide, which means changing to just define `OPENSSL_NO_ENGINE` is no longer fail-silent.
That's great news, I'm glad that there's a potential solution that doesn't inconvenience anyone!
*** Bug 2297642 has been marked as a duplicate of this bug. ***
While there is a potential solution, there is significant pushback on the Fedora developer mailing list to me actually implementing it. See https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RMQVMFJEBXR7PJNJ6I4EIHLXB6DS5TQW/, and specifically https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BNPDED6HABPGMEFANGGLEUQ6IXGY765R/ where I outline the situation. Only a single participant in that thread is favoring a fix before the F41 release, everybody else does not want to land a change improving this situation. I believe this is a bad user experience for users of Fedora, but it still seems ill-advised to start making a change now against the pushback on the mailing list. As a consequence, I am now closing this ticket as wontfix. Sorry, I really tried.
No worries, as I said, our issue is already fixed. I just hope that users who encountered this error will be able to find the (very easy) fix. Hopefully this ticket helps someone in finding the solution!
*** Bug 2312672 has been marked as a duplicate of this bug. ***