On Fri, Feb 6, 2026 at 5:22 PM Michael Osipov <[email protected]> wrote: > > On 2026/02/06 15:45:17 Rémy Maucherat wrote: > > On Fri, Feb 6, 2026 at 4:32 PM Mark Thomas <[email protected]> wrote: > > > > > > On 06/02/2026 14:10, Michael Osipov wrote: > > > > On 2026/02/06 13:22:12 Christopher Schultz wrote: > > > >> Michael, > > > >> > > > >> On 2/5/26 2:03 PM, Michael Osipov wrote: > > > >>> Hi Mark, > > > >>> > > > >>> On 2026/02/05 16:40:18 Mark Thomas wrote: > > > >>>> All, > > > >>>> > > > >>>> I think the niggles with the last releases have been ironed out and > > > >>>> the > > > >>>> deprecation warnings in 2.0.x have been fixed so I am planning on > > > >>>> tagging 1.3.x and 2.0.x shortly. I'm thinking tomorrow to give folks > > > >>>> a > > > >>>> chance to get any other changes they have been considering in before > > > >>>> I tag. > > > >>> > > > >>> Thank you for fixing the compiler warnings for pre-OpenSSL 3 APIs. I > > > >>> tried again to test with LibreSSL (Bug 64862). It does not compile > > > >>> (anymore). I think at some point we need stop lying to us and our > > > >>> users that we provide LibreSSL support as best effort. It should at > > > >>> least compile. Unless someone is willing to do the ifdefs we should > > > >>> rather drop support for it. > > > >> > > > >> I think tcnative 2.0 (which requires OpenSSL 3 or later) isn't going to > > > >> be able to support LibreSSL for a while. Either LibreSSL needs to > > > >> provide API compatibility, or tcnative does. > > > >> > > > >> Essentially undoing all the recent changes to remove deprecation > > > >> warnings in OpenSSL is definitely possible, then hiding those things > > > >> behind #ifdefs when LibreSSL is being used. > > > >> > > > >> The good news about doing that is most of these API incompatibilities > > > >> are constrained to within a few small functions, so, for now, things > > > >> shouldn't get out of hand. > > > >> > > > >> On the other hand, we recently removed a lot of code that was > > > >> backward-compatible with ancient OpenSSL precisely because the #ifdefs > > > >> were getting out of hand. > > > >> > > > >> tcnative 1.3.x still does compile against LibreSSL. I'll try to give it > > > >> a test this time around, both with OpenSSL and LibreSSL. > > > > > > > > I'd personally say that for the past couple of years almost no user > > > > stepped up to have decent LibreSSL support, we can't do it. Therefore, > > > > we should be safe to remove it. No one of us is testing actively. I > > > > have given up at some point years ago although I never used LibreSSL. > > > > > > I'd be happy dropping LibreSSL support. I'd also be happy merging PRs > > > from someone who wanted to see support continue. > > > > > > I could add a note to the changelog that those changes break LibreSSL > > > support and that absent a patch and/or PR to fix LibreSSL support we > > > anticipate removing it completely in a future release. > > > > I'm testing LibreSSL and BoringSSL with the FFM code and the Tomcat > > testsuite whenever something meaningful changes, but it won't test > > everything. > > It is suprising that it works with FFM, but fails to compile in C...
FFM acts the same as reflection, so as long as you don't try to access a missing symbol by calling it, it works fine (you can then catch the exception and ignore it). So maybe there are problems with LibreSSL, but they're not in the testsuite and I think the basics work ok. When I find an issue, I add some code to either disable a feature (like OCSP) or add an alternate call, but it is not the same way as using the preprocessor. Note: LibreSSL FFM support is also tested by the GitHub CI (they have LibreSSL 3.3.6). Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
