Hi Quentin, On Tue, Jun 16, 2026 at 6:43 PM Quentin Schulz <[email protected]> wrote: > > Hi Enric, > > Thanks for chiming in. > > On 6/4/26 8:22 AM, Enric Balletbo i Serra wrote: > > Hi Quentin and Eddie, > > > > On Fri, May 22, 2026 at 4:38 PM Quentin Schulz <[email protected]> > > wrote: > >> > >> Hi Eddie, > >> > >> On 5/22/26 12:29 AM, Eddie Kovsky wrote: > >>> On 05/12/26, Quentin Schulz wrote: > >>>> Hi Eddie, > >>>> > >>>> On 4/29/26 8:02 PM, Eddie Kovsky wrote: > [...] > > My understanding is that to fix the Fedora build issues without > > breaking existing workflows, Eddie just needs to adjust the control > > flow for v4 like you suggested: > > > > If the user explicitly commands an engine via -N, prioritize the > > legacy engine path—guarding the engine headers and blocks with #ifndef > > OPENSSL_NO_ENGINE instead of a blanket OpenSSL version check. > > > > If no engine flag is passed, route seamlessly into the new Provider API > > backend. > > Fix the build issue by checking whether OpenSSL engines are supported > (and no, a version check is not enough for OpenSSL 3.x (it is for > OpenSSL 4.x though)). If they are, keep the same logic as today. If they > aren't, fail hard when an engine is requested, otherwise keep the same > logic as today. Make use of #ifdef to guard code that cannot compile > when engine support is disabled and you should be good to go. This will > still fail unit tests because we are testing and building a dummy engine > regardless of support. But last time I checked (years ago), many > unrelated unit tests are also failing on Fedora, so it wouldn't be a > deal breaker for me (and I have some "interesting" ideas on how to > handle this in a later commit). >
This makes perfect sense to me. Since you already have a provider series in your local queue, pivoting v4 to strictly implement these compile-guards looks like the best path forward. I also appreciate the clarification regarding the unit tests, knowing that the expected dummy engine test failures block the patch, as they did before. > Also, please do not use USE_PKCS11_PROVIDER when it has nothing to do > with PKCS11 provider. I understand this was imported from the kernel, > but they do only support PKCS11 as far as I could tell, so it makes > sense for them. > I agree now that I have a bit more knowledge. > I honestly don't want to see the Provider/Store API being used only for > loading simple keys. It already works without the provider API and isn't > deprecated as far as I know? Let someone who's interested (my employer > is, therefore I have to be :) ) in supporting OpenSSL providers do the > work of implementing support for OpenSSL providers, with unit tests, > backward compatibility with engines through the OpenSSL provider API, etc... > Agreed if protecting backward compatibility for OpenSSL 1.x distributions are critical, and we definitely shouldn't break those existing legacy engine setups. > For PKCS11, we have some interesting logic for the OpenSSL engine, and I > think we may want something similar for the OpenSSL provider. > > Note that OpenSSL 1.x is still used in some distros (Bullseye, Slackware > 15, AlmaLinux/RockyLinux 8 according to pkgs.org) so I think it's still > premature to entirely remove OpenSSL engine support (and OpenSSL 1.x > doesn't have the provider API). > > > > > This fixes the compilation bottleneck on some distros, completely > > preserves legacy engine setups, and allows real providers URI > > string-mangling issue to be handled as clean, independent follow-up > > patches. > > > > We need proper unit tests for supporting OpenSSL providers (and not only > a local key using the Provider/Store API). I'll repeat it once more, I > have local WIP (but tested) patches for OpenSSL provider support, so I > don't think it makes sense for someone to redo the work. The fact this > was started back in November 2025 and it hasn't been really pushed hard > since kinda hinted at this not being a big issue for RH (or they keep > their stuff downstream and upstream can take the time it'll take), hence > why I was waiting for Eddie to answer/send a new version (I've also been > swamped at work for a few weeks, which should end soon hopefully, so it > also worked out for me to wait on Eddie). > Knowing that, there is no reason to duplicate your efforts. Please cc me when you send it upstream, as I'm interested. > > Does it makes sense? > > > > Somewhat. I still don't understand the obsession with the Provider API > when the issue (as I understand it) is "I cannot compile OpenSSL engine > support and I don't need it". > To clarify the "obsession" point, which I think is an unfortunate take, my impression was that this wasn't just about throwing a quick, blind hack at a Fedora compiler error. The build failure was simply the trigger. Eddie put significant effort into researching the modern OpenSSL 3.x API, studying how to phase out legacy, deprecated components, looking at the U-Boot's testing infrastructure, and trying to proactively modernize U-Boot's backend based on established upstream kernel patterns. I agree, now, and this is the beauty of discussions, that the kernel approach is not enough due to its narrow scope. U-Boot’s edge cases make a full API migration heavier than expected. However, trying to actively clean up technical debt is a valuable goal, and characterizing it as a mere obsession with a build error can be quite discouraging for new contributors putting in real work to improve the codebase. That said, if Eddie is willing to do so, keeping that patch focused strictly on the #ifndef compile-guards looks like the right approach to me too, and it leaves the runway entirely clear for your provider migration patches later. Cheers, Enric > Cheers, > Quentin >
