Created attachment 187402 [details]
haproxy-devel is again broken with LibreSSL :)
This patch fixes build. I have run-tested it and it's fine.
Can you please push this upstream (finally)?
I don't understand the "finally?" remark. I have been supplying upstream with the patches as well but there's no bug tracker of any sort where I can track this.
Piotr: Can you please upstream this patch to email@example.com as well?
(In reply to Dmitry Sivachenko from comment #1)
I wrote the earlier version of this patch in February and sent it to the Haproxy ML. Willy rejected this patch, because it adds one warning. Meanwhile, Haproxy 1.8d1 has been working just fine. I had problems with d2, but d3 seems fine, the patched Haproxy is certainly stable.
OpenBSD guys also imported my patch and they don't seem to complain about stability of Haproxy.
Given that, can't you just import it? As you can see, it only adds additional check (for LIBRESSL_VERSION_NUMBER), which is definitely not defined when base OpenSSL is used. It only matters if you use LibreSSL.
(In reply to Bernard Spil from comment #2)
"Finally" means that we came to this subject before, I already expressed a concern that
FreeBSD ports is not a proper place for such changes and advised to push this upstream.
You send a patch to haproxy ML, but after receiving some feedback from the author you disappeared, so this task was stuck. See:
Since you clearly have enough energy to maintain these changes here, I am kindly ask you again to spend this energy pushing this upstream, for the benefit of the whole community, not only FreeBSD ports users.
Thanks for your understanding.
(In reply to Piotr Kubaj from comment #3)
FWIW 3rd chunk of your patch (regarding SSL_CTRL_GET_TLSEXT_STATUS_REQ_CB) is not protected with LIBRESSL_VERSION_NUMBER check.
Created attachment 187439 [details]
git diff for HEAD
git diff as per upstream specs
Created attachment 187440 [details]
svn diff for net/haproxy-devel
Full svn diff, update to 1.8-dev3
Fixes error in the supplied patch
!defined LIBRESSL_VERSION_NUMBER) will not work
Dimitry, if FreeBSD is not the place to hold LibreSSL patches for upstream inclusion then the chances of having LibreSSL supported by upstream are diminished. With it, the usefulness of LibreSSL support in ports is forcefully lowered.
This has been open for 5 months. Tell me, how much work does this generate for you?
This is not only about the work generated for me. OpenSSL is complex beast, and making changes for LibreSSL could possible affect OpenSSL.
Yes I see that time flies and LibreSSL support is not included upstream still.
But I also see that nobody pings authors about it (there is more discussion in that PR rather than in haproxy ML).
The right solution would be to revive the thread mentioned in this PR and push it upstream, so everyone will benefit from native LibreSSL support.
I'll see what I can do WRT upstream taking these patches, ok. :)
(In reply to Dmitry Sivachenko from comment #9)
You're right that there's no discussion in haproxy ML about this issue. But it's because users of systems that use LibreSSL already have this patch in their repositories and can just install haproxy without patching anything.
Here's a patch for OpenBSD: https://github.com/openbsd/ports/blob/master/net/haproxy/patches/patch-src_ssl_sock_c
Alpine Linux: https://git.alpinelinux.org/cgit/aports/tree/main/haproxy/fix-libressl-2.5.patch
And Void Linux: https://github.com/voidlinux/void-packages/blob/master/srcpkgs/haproxy/patches/fix-libressl-2.5.patch
So there's no need for users to ask about this issue on ML. That would be maintainer's job, but I guess they already can see that haproxy's developers don't want haproxy to be compatible with LibreSSL and decided to just have this patch.
I don't really see the issue here - many other ports have patches for LibreSSL. What's wrong with haproxy having it?
(In reply to Piotr Kubaj from comment #11)
As I already mentioned: maintaining this patch requires solid knowledge of *SSL api and it is not as simple as it seems at the first glance. Just because SSL api is rather complex.
That is another reason why it is not easy to push it upstream: it required thorough analysis so that this patch does not break another SSL flavour.
I never heard that authors do not want LibreSSL support upstream.
The number of distros you mention just proves that it would be beneficial for everyone to finally push these changes upstream: it just requires to sort out rough corners in collaboration with authors.
(In reply to Dmitry Sivachenko from comment #12)
I am happy to colaborate with them, but they also need to colaborate.
And that's the issue, I didn't see any will to colaborate. It's not like I can force them to do it, although I imagine if more people storm haproxy ML about this issue, maybe they will somehow see the need to commit this patch. Maybe you, as a maintainer of haproxy could also try to push this issue? I don't think I can do more about it on my own.