Bug 2296114
| Summary: | OPENSSL_NO_ENGINE not defined in include directory | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | whatdoinamemyself1101 |
| Component: | openssl | Assignee: | Clemens Lang <cllang> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | cllang, crypto-team, dbelyavs, js-fedora, jwakely, mikel, mspacek, mturk, rjones, shebburn, suraj.ghimire7, tm |
| Target Milestone: | --- | Keywords: | Regression, Triaged |
| Target Release: | --- | Flags: | fedora-admin-xmlrpc:
mirror+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-07-24 15:07:58 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
whatdoinamemyself1101
2024-07-06 17:45:44 UTC
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. *** *** Bug 2312672 has been marked as a duplicate of this bug. *** |