Bug 223196 - net/haproxy-devel: fix build with LibreSSL
Summary: net/haproxy-devel: fix build with LibreSSL
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Walter Schwarzenfeld
Depends on:
Reported: 2017-10-23 18:22 UTC by Piotr Kubaj
Modified: 2019-08-18 14:31 UTC (History)
5 users (show)

See Also:
bugzilla: maintainer-feedback? (demon)

patch (3.49 KB, text/x-csrc)
2017-10-23 18:22 UTC, Piotr Kubaj
no flags Details
git diff for HEAD (6.41 KB, application/mbox)
2017-10-24 14:27 UTC, Bernard Spil
no flags Details
svn diff for net/haproxy-devel (7.67 KB, patch)
2017-10-24 14:31 UTC, Bernard Spil
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Kubaj freebsd_committer 2017-10-23 18:22:06 UTC
Created attachment 187402 [details]

haproxy-devel is again broken with LibreSSL :)

This patch fixes build. I have run-tested it and it's fine.
Comment 1 Dmitry Sivachenko freebsd_committer 2017-10-24 09:59:13 UTC
Can you please push this upstream (finally)?
Comment 2 Bernard Spil freebsd_committer 2017-10-24 10:43:05 UTC
Hi Dmitry,

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.

See https://www.mail-archive.com/haproxy@formilux.org/msg26629.html

Piotr: Can you please upstream this patch to haproxy@formilux.org as well?
Comment 3 Piotr Kubaj freebsd_committer 2017-10-24 10:57:00 UTC
(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.
Comment 4 Dmitry Sivachenko freebsd_committer 2017-10-24 10:57:57 UTC
(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.
Comment 5 Dmitry Sivachenko freebsd_committer 2017-10-24 10:59:47 UTC
(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.
Comment 6 Bernard Spil freebsd_committer 2017-10-24 14:27:59 UTC
Created attachment 187439 [details]
git diff for HEAD

git diff as per upstream specs
Comment 7 Bernard Spil freebsd_committer 2017-10-24 14:31:23 UTC
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
Comment 8 Franco Fichtner 2018-02-04 09:54:00 UTC
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?
Comment 9 Dmitry Sivachenko freebsd_committer 2018-02-08 07:59:19 UTC
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.
Comment 10 Franco Fichtner 2018-02-08 08:15:46 UTC
I'll see what I can do WRT upstream taking these patches, ok. :)
Comment 11 Piotr Kubaj freebsd_committer 2018-02-08 16:28:04 UTC
(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?
Comment 12 Dmitry Sivachenko freebsd_committer 2018-02-08 21:08:27 UTC
(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.
Comment 13 Piotr Kubaj freebsd_committer 2018-02-08 21:23:26 UTC
(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.
Comment 14 Walter Schwarzenfeld freebsd_triage 2019-08-18 14:31:45 UTC
We have now:

DISTVERSION=    2.0-dev7

builds fine with libressl (without patch).

I close here. If there are still problems , please reopen.