Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
пт, 12 июн. 2020 г. в 21:09, Willy Tarreau : > On Fri, Jun 12, 2020 at 08:57:44PM +0500, ??? wrote: > > ??, 12 ???. 2020 ?. ? 20:46, Willy Tarreau : > > > > > On Fri, Jun 12, 2020 at 08:11:52PM +0500, ??? wrote: > > > > > Has it ever reported a *real* issue ? I mean, we've been working > around > > > > > > > > > > > > > > > > > https://github.com/haproxy/haproxy/issues/96 > > > > https://github.com/haproxy/haproxy/issues/104 > > > > https://github.com/haproxy/haproxy/issues/106 > > > > https://github.com/haproxy/haproxy/issues/111 > > > > > > Well only two above are the address sanitizer, one is valgrind and the > > > other one is the thread sanitizer. > > > > > > > and I hope that William Lallemand also found and fixed about 5 bugs > > > > detected by travis + asan > > > > > > Maybe. > > > > > > In that case at least we should run it at -O1. It's at -O2 that it > > > produces bogus code from what I'm seeing. And given that the docs > > > also suggest -O1 to get a usable backtrace, it's possible that it's > > > rarely tested in combination with -O2. But anyway I really *hate* > > > seeing compilers silently emit bad code, especially when it happens > > > when asking them to detect more anomalies! > > > > > > > I may try to report it. Is there small repro code ? > > Sadly not, as usual with bad code. It dies in b_alloc_margin() with a > NULL "buf" (long after having successfully dereferenced it) when getting > the first H2 request. Putting a printf() in the caller (h2_get_buf) is > usually enough to stop the bug. However a printf in the caller doesn't > change anything, which could indicate that we may succeed in isolating > these functions. I saw it crash when buf was assigned to rbx register, > maybe it's occasionally clobbered by their functions, I don't know. > I've spent way too much time on it now. I may try to elaborate a repro > later but I have way more important things to do than trying to debug > an experimental tool that's broken in other areas anyway :-/ > I'll play with recent builds on travis switching -O2 <--> -O1 > > Willy >
[ANNOUNCE] haproxy-2.0.15
Hi, HAProxy 2.0.15 was released on 2020/06/12. It added 77 new commits after version 2.0.14. A major issue was fixed when using l7 retries which could provokes a crash. The fix had to be done in a different way than in 2.1+ since the architecture changed a lot. If you want more details about it, please read the commit message. A very difficult to trigger risk of crash was also fixed when connecting to a server using ALPN but haproxy fails to find a mux after the TLS handshake. Some fixes were made with captures converters that could crash if misued as well as some buggy sample fetches (http_first_req, unique-id, CPU, latency). An HTTP reuse issue was fixed when using NTML authentication, this was fixed by using a safer test for making the NTML sessions private. Some inconsistencies in the argument parser were also fixed, the parameter of all options now support a hyphen as a first character except the -sf/st ones. We also fixed the support of the "--" option in the mworker mode, which is useful at the end of the command when you want to use a list of configuration files. Find the complete changelog below. As usual, don't forget to update to this version if you are using the 2.0 branch. Please find the usual URLs below : Site index : http://www.haproxy.org/ Discourse: http://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Sources : http://www.haproxy.org/download/2.0/src/ Git repository : http://git.haproxy.org/git/haproxy-2.0.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy-2.0.git Changelog: http://www.haproxy.org/download/2.0/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ --- Complete changelog : Adam Mills (1): DOC: hashing: update link to hashing functions Adis Nezirovic (1): BUG/MEDIUM: lua: Fix dumping of stick table entries for STD_T_DICT Christopher Faulet (20): BUG/MINOR: check: Update server address and port to execute an external check MINOR: checks: Add a way to send custom headers and payload during http chekcs BUG/MINOR: checks: Respect the no-check-ssl option BUG/MINOR: obj_type: Handle stream object in obj_base_ptr() function BUG/MEDIUM: server/checks: Init server check during config validity check BUG/MINOR: checks/server: use_ssl member must be signed BUG/MEDIUM: checks: Always initialize checks before starting them BUG/MINOR: checks: Compute the right HTTP request length for HTTP health checks BUG/MINOR: checks: Remove a warning about http health checks BUG/MINOR: sample: Set the correct type when a binary is converted to a string BUG/MINOR: config: Make use_backend and use-server post-parsing less obscur BUG/MINOR: cache: Don't needlessly test "cache" keyword in parse_cache_flt() BUG/MINOR: checks: Respect check-ssl param when a port or an addr is specified BUG/MINOR: server: Fix server_finalize_init() to avoid unused variable BUG/MEDIUM: lua: Reset analyse expiration timeout before executing a lua action BUG/MEDIUM: hlua: Lock pattern references to perform set/add/del operations BUG/MEDIUM: contrib/prometheus-exporter: Properly set flags to dump metrics BUG/MINOR: proto-http: Fix detection of NTLM for the legacy HTTP version REGTESTS: Add missing OPENSSL to REQUIRE_OPTIONS for compression/lua_validation REGTESTS: checks: Fix tls_health_checks when IPv6 addresses are used Dragan Dosen (1): BUG/MEDIUM: ssl: fix the id length check within smp_fetch_ssl_fc_session_id() Emeric Brun (3): BUG/MINOR: peers: fix internal/network key type mapping. BUG/MINOR: logs: prevent double line returns in some events. BUG/MEDIUM: logs: fix trailing zeros on log message. Frédéric Lécaille (2): BUG/MINOR: protocol_buffer: Wrong maximum shifting. BUG/MINOR: peers: Incomplete peers sections should be validated. Gaetan Rivet (1): BUG/MINOR: checks: chained expect will not properly wait for enough data Jerome Magnin (3): BUG/MINOR: ssl: default settings for ssl server options are not used DOC: option logasap does not depend on mode BUILD: select: only declare existing local labels to appease clang Nathan Neulinger (1): BUG/MINOR: lua: Add missing string length for lua sticktable lookup Olivier Doucet (1): DOC: Improve documentation on http-request set-src Olivier Houchard (3): BUG/MEDIUM: http-ana: Handle NTLM messages correctly. BUG/MEDIUM: streams: Remove SF_ADDR_SET if we're retrying due to L7 retry. BUG/MEDIUM: stream: Only allow L7 retries when using HTTP. Tim Duesterhus (2): BUG/MINOR: cfgparse: Abort parsing the current line if an invalid \x sequence is encountered REGTESTS: Add missing OPENSSL to REQUIRE_OPTIONS for lua/txn_get_priv William Dauchy (4):
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
On Fri, Jun 12, 2020 at 08:57:44PM +0500, ??? wrote: > ??, 12 ???. 2020 ?. ? 20:46, Willy Tarreau : > > > On Fri, Jun 12, 2020 at 08:11:52PM +0500, ??? wrote: > > > > Has it ever reported a *real* issue ? I mean, we've been working around > > > > > > > > > > > > > https://github.com/haproxy/haproxy/issues/96 > > > https://github.com/haproxy/haproxy/issues/104 > > > https://github.com/haproxy/haproxy/issues/106 > > > https://github.com/haproxy/haproxy/issues/111 > > > > Well only two above are the address sanitizer, one is valgrind and the > > other one is the thread sanitizer. > > > > > and I hope that William Lallemand also found and fixed about 5 bugs > > > detected by travis + asan > > > > Maybe. > > > > In that case at least we should run it at -O1. It's at -O2 that it > > produces bogus code from what I'm seeing. And given that the docs > > also suggest -O1 to get a usable backtrace, it's possible that it's > > rarely tested in combination with -O2. But anyway I really *hate* > > seeing compilers silently emit bad code, especially when it happens > > when asking them to detect more anomalies! > > > > I may try to report it. Is there small repro code ? Sadly not, as usual with bad code. It dies in b_alloc_margin() with a NULL "buf" (long after having successfully dereferenced it) when getting the first H2 request. Putting a printf() in the caller (h2_get_buf) is usually enough to stop the bug. However a printf in the caller doesn't change anything, which could indicate that we may succeed in isolating these functions. I saw it crash when buf was assigned to rbx register, maybe it's occasionally clobbered by their functions, I don't know. I've spent way too much time on it now. I may try to elaborate a repro later but I have way more important things to do than trying to debug an experimental tool that's broken in other areas anyway :-/ Willy
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
пт, 12 июн. 2020 г. в 20:46, Willy Tarreau : > On Fri, Jun 12, 2020 at 08:11:52PM +0500, ??? wrote: > > > Has it ever reported a *real* issue ? I mean, we've been working around > > > > > > > > > https://github.com/haproxy/haproxy/issues/96 > > https://github.com/haproxy/haproxy/issues/104 > > https://github.com/haproxy/haproxy/issues/106 > > https://github.com/haproxy/haproxy/issues/111 > > Well only two above are the address sanitizer, one is valgrind and the > other one is the thread sanitizer. > > > and I hope that William Lallemand also found and fixed about 5 bugs > > detected by travis + asan > > Maybe. > > In that case at least we should run it at -O1. It's at -O2 that it > produces bogus code from what I'm seeing. And given that the docs > also suggest -O1 to get a usable backtrace, it's possible that it's > rarely tested in combination with -O2. But anyway I really *hate* > seeing compilers silently emit bad code, especially when it happens > when asking them to detect more anomalies! > I may try to report it. Is there small repro code ? > > Willy >
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
On Fri, Jun 12, 2020 at 08:11:52PM +0500, ??? wrote: > > Has it ever reported a *real* issue ? I mean, we've been working around > > > > > https://github.com/haproxy/haproxy/issues/96 > https://github.com/haproxy/haproxy/issues/104 > https://github.com/haproxy/haproxy/issues/106 > https://github.com/haproxy/haproxy/issues/111 Well only two above are the address sanitizer, one is valgrind and the other one is the thread sanitizer. > and I hope that William Lallemand also found and fixed about 5 bugs > detected by travis + asan Maybe. In that case at least we should run it at -O1. It's at -O2 that it produces bogus code from what I'm seeing. And given that the docs also suggest -O1 to get a usable backtrace, it's possible that it's rarely tested in combination with -O2. But anyway I really *hate* seeing compilers silently emit bad code, especially when it happens when asking them to detect more anomalies! Willy
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
пт, 12 июн. 2020 г. в 20:01, Willy Tarreau : > On Fri, Jun 12, 2020 at 07:52:48PM +0500, ??? wrote: > > it should be detectable using > > > > #if defined(__has_feature)# if __has_feature(address_sanitizer)// > > code that builds only under AddressSanitizer# endif#endif > > OK that could be useful indeed, thanks! > > > I agree to remove asan from travis. However, I still find it somewhat > > useful, I would add daily github action job with asan enabled (in the > > way it would not bother anymore). > > Has it ever reported a *real* issue ? I mean, we've been working around > https://github.com/haproxy/haproxy/issues/96 https://github.com/haproxy/haproxy/issues/104 https://github.com/haproxy/haproxy/issues/106 https://github.com/haproxy/haproxy/issues/111 and I hope that William Lallemand also found and fixed about 5 bugs detected by travis + asan > its bugs but beyond this ? This looks like totally experimental junk to > me when I see how simple code paths get ruined. I've stopped looking at > travis reports again because when I start my browser, it loads with a > red tab and I already predict it will be on the clang builds. Having > something constantly cry wolf serves no purpose. Also, it seems to be > highly sensitive to the initialization ordering and randomly fails > during startup if you build without USE_OBSOLETE_LINKER. That's a real > PITA which currently only adds noise. > > Willy >
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
On Fri, Jun 12, 2020 at 07:52:48PM +0500, ??? wrote: > it should be detectable using > > #if defined(__has_feature)# if __has_feature(address_sanitizer)// > code that builds only under AddressSanitizer# endif#endif OK that could be useful indeed, thanks! > I agree to remove asan from travis. However, I still find it somewhat > useful, I would add daily github action job with asan enabled (in the > way it would not bother anymore). Has it ever reported a *real* issue ? I mean, we've been working around its bugs but beyond this ? This looks like totally experimental junk to me when I see how simple code paths get ruined. I've stopped looking at travis reports again because when I start my browser, it loads with a red tab and I already predict it will be on the clang builds. Having something constantly cry wolf serves no purpose. Also, it seems to be highly sensitive to the initialization ordering and randomly fails during startup if you build without USE_OBSOLETE_LINKER. That's a real PITA which currently only adds noise. Willy
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
пт, 12 июн. 2020 г. в 19:31, Willy Tarreau : > Hi Ilya, > > On Mon, Mar 16, 2020 at 10:49:26AM +0100, Tim Düsterhus wrote: > > Ilya, > > > > Am 16.03.20 um 07:52 schrieb ???: > > > we use clang because of its address sanitizer. I found gcc asan more > noisy > > > and less usable. > > Going back to this, I spent the whole day trying to figure what broke > on travis to finally find that it's clang's broken ASAN which generates > bad code at -O2. Function b_alloc_margin() sees its "buf" pointer change > from valid to null in the middle of the function while not being assigned. > Just printing it or assigning it from itself is enough to stop the bug, I > suspect it's doing something wrong with the register where it placed the > pointer. I'm really fed up with this bogus address sanitizer, it has wasted > a huge amount of time and patience trying to find bugs that did not exist > and > because of this yet-another fake one I haven't finished addressing a real > one :-( > > Could we once for all disable this monster crap and mention in the commit > message that it must never be turned on until it stops doing stupid things > ? > > Sadly I couldn't find a way to detect it from within the code. I'd like > to prevent haproxy from being built with this crap without explicit > debug flags because the wrong code it produces triggers segfaults at > runtime in random locations and as such it's extremely dangerous. There's > definitely a risk that some people are not aware of its breakage and would > build haproxy with it and run it on their production, which is scary. If > anyone knows how to reliably detect it (ideally at build time), feel free > to suggest! > it should be detectable using #if defined(__has_feature)# if __has_feature(address_sanitizer)// code that builds only under AddressSanitizer# endif#endif I agree to remove asan from travis. However, I still find it somewhat useful, I would add daily github action job with asan enabled (in the way it would not bother anymore). > Thanks, > Willy >
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
Hi Ilya, On Mon, Mar 16, 2020 at 10:49:26AM +0100, Tim Düsterhus wrote: > Ilya, > > Am 16.03.20 um 07:52 schrieb ???: > > we use clang because of its address sanitizer. I found gcc asan more noisy > > and less usable. Going back to this, I spent the whole day trying to figure what broke on travis to finally find that it's clang's broken ASAN which generates bad code at -O2. Function b_alloc_margin() sees its "buf" pointer change from valid to null in the middle of the function while not being assigned. Just printing it or assigning it from itself is enough to stop the bug, I suspect it's doing something wrong with the register where it placed the pointer. I'm really fed up with this bogus address sanitizer, it has wasted a huge amount of time and patience trying to find bugs that did not exist and because of this yet-another fake one I haven't finished addressing a real one :-( Could we once for all disable this monster crap and mention in the commit message that it must never be turned on until it stops doing stupid things ? Sadly I couldn't find a way to detect it from within the code. I'd like to prevent haproxy from being built with this crap without explicit debug flags because the wrong code it produces triggers segfaults at runtime in random locations and as such it's extremely dangerous. There's definitely a risk that some people are not aware of its breakage and would build haproxy with it and run it on their production, which is scary. If anyone knows how to reliably detect it (ideally at build time), feel free to suggest! Thanks, Willy
Re: [PATCH] BUG/MEDIUM: checks: Fix off-by-one in allocation of SMTP greeting cmd
On Fri, Jun 12, 2020 at 03:58:48PM +0200, Tim Duesterhus wrote: > The allocation did not account for either the trailing null byte or the > space, leading to a buffer overwrite. (...) Indeed, applied now. Thank you Tim! Willy
Re: Ubuntu 20.04 + TLSv1
Am Fr., 12. Juni 2020 um 16:02 Uhr schrieb Jerome Magnin : > On Fri, Jun 12, 2020 at 03:09:18PM +0200, bjun...@gmail.com wrote: > > Hi, > > > > currently i'm testing Ubuntu 20.04 and HAProxy 2.0.14. > > > > I'm trying to get TLSv1 working (we need this for some legacy clients), > so > > far without success. > > > > I've read different things, on the one hand Ubuntu has removed > > TLSv1/TLSv1.1 support completely, otherwise that it can be enabled: > > > http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.1.1f-1ubuntu2/changelog > > > > > > Is there anything that can be set in HAProxy? (apart from > > "ssl-default-bind-options ssl-min-ver TLSv1.0 ssl-max-ver TLSv1.2") > > > > Has anybody more information on this matter or has TLSv1 working in > Ubuntu > > 20.04 + HAProxy? > > > > Hi, > > appending @SECLEVEL=1 to the cipher string I can perform the handshakes > using TLSv1.0 and higher on ubuntu 20.04. You don't need to rebuild > openssl. I was not able to use s_client -tls1 or -tls1_2 on the 20.04 > though, had to try with a different client. It's probably something that > you can handle with openssl.cnf, just like the ciphers. > > frontend in > bind *:8443 ssl crt ssl.pem ssl-min-ver TLSv1.0 ciphers ALL:@SECLEVEL=1 > > > -- > Jérôme > Thanks Jérôme, that does the trick. Best regards / Mit freundlichen Grüßen Bjoern
Re: Ubuntu 20.04 + TLSv1
On Fri, Jun 12, 2020 at 03:09:18PM +0200, bjun...@gmail.com wrote: > Hi, > > currently i'm testing Ubuntu 20.04 and HAProxy 2.0.14. > > I'm trying to get TLSv1 working (we need this for some legacy clients), so > far without success. > > I've read different things, on the one hand Ubuntu has removed > TLSv1/TLSv1.1 support completely, otherwise that it can be enabled: > http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.1.1f-1ubuntu2/changelog > > > Is there anything that can be set in HAProxy? (apart from > "ssl-default-bind-options ssl-min-ver TLSv1.0 ssl-max-ver TLSv1.2") > > Has anybody more information on this matter or has TLSv1 working in Ubuntu > 20.04 + HAProxy? > Hi, appending @SECLEVEL=1 to the cipher string I can perform the handshakes using TLSv1.0 and higher on ubuntu 20.04. You don't need to rebuild openssl. I was not able to use s_client -tls1 or -tls1_2 on the 20.04 though, had to try with a different client. It's probably something that you can handle with openssl.cnf, just like the ciphers. frontend in bind *:8443 ssl crt ssl.pem ssl-min-ver TLSv1.0 ciphers ALL:@SECLEVEL=1 -- Jérôme
[PATCH] BUG/MEDIUM: checks: Fix off-by-one in allocation of SMTP greeting cmd
The allocation did not account for either the trailing null byte or the
space, leading to a buffer overwrite.
This bug was detected by an assertion failure in the allocator. But can
also be easily detected using valgrind:
==25827== Invalid write of size 1
==25827==at 0x6529759: __vsprintf_chk (vsprintf_chk.c:84)
==25827==by 0x65296AC: __sprintf_chk (sprintf_chk.c:31)
==25827==by 0x4D6AB7: sprintf (stdio2.h:33)
==25827==by 0x4D6AB7: proxy_parse_smtpchk_opt (check.c:1799)
==25827==by 0x4A7DDD: cfg_parse_listen (cfgparse-listen.c:2269)
==25827==by 0x494AD3: readcfgfile (cfgparse.c:2167)
==25827==by 0x542995: init (haproxy.c:2021)
==25827==by 0x421DD2: main (haproxy.c:3121)
==25827== Address 0x78712a8 is 0 bytes after a block of size 24 alloc'd
==25827==at 0x4C2FB55: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25827==by 0x4D6A8C: proxy_parse_smtpchk_opt (check.c:1797)
==25827==by 0x4A7DDD: cfg_parse_listen (cfgparse-listen.c:2269)
==25827==by 0x494AD3: readcfgfile (cfgparse.c:2167)
==25827==by 0x542995: init (haproxy.c:2021)
==25827==by 0x421DD2: main (haproxy.c:3121)
This patch fixes issue #681.
This bug was introduced in commit fbcc77c6baa7edee85be9c2384d12c55ef651a5a,
which first appeared in 2.2-dev7. No backport needed.
---
src/check.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/check.c b/src/check.c
index 82f18e3a0..c9802a603 100644
--- a/src/check.c
+++ b/src/check.c
@@ -1794,7 +1794,8 @@ int proxy_parse_smtpchk_opt(char **args, int cur_arg,
struct proxy *curpx, struc
cur_arg += 2;
if (*args[cur_arg] && *args[cur_arg+1] &&
(strcmp(args[cur_arg], "EHLO") == 0 || strcmp(args[cur_arg],
"HELO") == 0)) {
- cmd = calloc(strlen(args[cur_arg]) + strlen(args[cur_arg+1]) +
1, sizeof(*cmd));
+ /* + space (1) + + null byte (1) */
+ cmd = calloc(strlen(args[cur_arg]) + 1 +
strlen(args[cur_arg+1]) + 1, sizeof(*cmd));
if (cmd)
sprintf(cmd, "%s %s", args[cur_arg], args[cur_arg+1]);
}
--
2.27.0
Re: Ubuntu 20.04 + TLSv1
Am Fr., 12. Juni 2020 um 15:38 Uhr schrieb bjun...@gmail.com < bjun...@gmail.com>: > Am Fr., 12. Juni 2020 um 15:24 Uhr schrieb Lukas Tribus : > >> Hello Bjoern, >> >> >> On Fri, 12 Jun 2020 at 15:09, bjun...@gmail.com >> wrote: >> > >> > Hi, >> > >> > currently i'm testing Ubuntu 20.04 and HAProxy 2.0.14. >> > >> > I'm trying to get TLSv1 working (we need this for some legacy clients), >> so far without success. >> > >> > I've read different things, on the one hand Ubuntu has removed >> TLSv1/TLSv1.1 support completely, otherwise that it can be enabled: >> http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.1.1f-1ubuntu2/changelog >> > >> > Is there anything that can be set in HAProxy? (apart from >> "ssl-default-bind-options ssl-min-ver TLSv1.0 ssl-max-ver TLSv1.2") >> > >> > Has anybody more information on this matter or has TLSv1 working in >> Ubuntu 20.04 + HAProxy? >> >> >> Please try "force-tlsv10" *directly* on the bind line (not from >> ssl-default-bind-options). >> >> There are two issues: >> >> Bug 595 [1]: ssl-min-ver does not work from ssl-default-bind-options >> Bug 676 [2]: ssl-min-ver does not work properly depending on OS defaults >> >> If force-tlsv10 works directly on the bind line to enable TLSv1.0, >> then the next release 2.0.15 should work fine as it contains both >> fixes. >> >> >> >> Regards, >> >> Lukas >> >> >> [1] https://github.com/haproxy/haproxy/issues/595 >> [2] https://github.com/haproxy/haproxy/issues/676 > > > > Hi Lukas, > > "force-tlsv10" directly on the bind line doesn't work (i've also tried in > "ssl-default-bind-options", same result). > > Best regards / Mit freundlichen Grüßen > Bjoern > > I'm using the ubuntu packages from haproxy.debian.net. # haproxy -vvv | grep -i openssl OPTIONS = USE_PCRE2=1 USE_PCRE2_JIT=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 USE_ZLIB=1 USE_SYSTEMD=1 Feature list : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER -PCRE -PCRE_JIT +PCRE2 +PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED +REGPARM -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT +CRYPT_H -VSYSCALL +GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4 -MY_ACCEPT4 +ZLIB -SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL +SYSTEMD -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS Built with OpenSSL version : OpenSSL 1.1.1d 10 Sep 2019 Running on OpenSSL version : OpenSSL 1.1.1f 31 Mar 2020 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3 Best regards / Mit freundlichen Grüßen Bjoern
Re: Ubuntu 20.04 + TLSv1
Am Fr., 12. Juni 2020 um 15:24 Uhr schrieb Lukas Tribus : > Hello Bjoern, > > > On Fri, 12 Jun 2020 at 15:09, bjun...@gmail.com wrote: > > > > Hi, > > > > currently i'm testing Ubuntu 20.04 and HAProxy 2.0.14. > > > > I'm trying to get TLSv1 working (we need this for some legacy clients), > so far without success. > > > > I've read different things, on the one hand Ubuntu has removed > TLSv1/TLSv1.1 support completely, otherwise that it can be enabled: > http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.1.1f-1ubuntu2/changelog > > > > Is there anything that can be set in HAProxy? (apart from > "ssl-default-bind-options ssl-min-ver TLSv1.0 ssl-max-ver TLSv1.2") > > > > Has anybody more information on this matter or has TLSv1 working in > Ubuntu 20.04 + HAProxy? > > > Please try "force-tlsv10" *directly* on the bind line (not from > ssl-default-bind-options). > > There are two issues: > > Bug 595 [1]: ssl-min-ver does not work from ssl-default-bind-options > Bug 676 [2]: ssl-min-ver does not work properly depending on OS defaults > > If force-tlsv10 works directly on the bind line to enable TLSv1.0, > then the next release 2.0.15 should work fine as it contains both > fixes. > > > > Regards, > > Lukas > > > [1] https://github.com/haproxy/haproxy/issues/595 > [2] https://github.com/haproxy/haproxy/issues/676 Hi Lukas, "force-tlsv10" directly on the bind line doesn't work (i've also tried in "ssl-default-bind-options", same result). Best regards / Mit freundlichen Grüßen Bjoern
Re: Ubuntu 20.04 + TLSv1
Hello Bjoern, On Fri, 12 Jun 2020 at 15:09, bjun...@gmail.com wrote: > > Hi, > > currently i'm testing Ubuntu 20.04 and HAProxy 2.0.14. > > I'm trying to get TLSv1 working (we need this for some legacy clients), so > far without success. > > I've read different things, on the one hand Ubuntu has removed TLSv1/TLSv1.1 > support completely, otherwise that it can be enabled: > http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.1.1f-1ubuntu2/changelog > > Is there anything that can be set in HAProxy? (apart from > "ssl-default-bind-options ssl-min-ver TLSv1.0 ssl-max-ver TLSv1.2") > > Has anybody more information on this matter or has TLSv1 working in Ubuntu > 20.04 + HAProxy? Please try "force-tlsv10" *directly* on the bind line (not from ssl-default-bind-options). There are two issues: Bug 595 [1]: ssl-min-ver does not work from ssl-default-bind-options Bug 676 [2]: ssl-min-ver does not work properly depending on OS defaults If force-tlsv10 works directly on the bind line to enable TLSv1.0, then the next release 2.0.15 should work fine as it contains both fixes. Regards, Lukas [1] https://github.com/haproxy/haproxy/issues/595 [2] https://github.com/haproxy/haproxy/issues/676
Re: Ubuntu 20.04 + TLSv1
if haproxy was built against openssl with disabled TLS1.0, so haproxy does not support TLS1.0 you need to rebuild haproxy after enabling пт, 12 июн. 2020 г. в 18:12, bjun...@gmail.com : > Hi, > > currently i'm testing Ubuntu 20.04 and HAProxy 2.0.14. > > I'm trying to get TLSv1 working (we need this for some legacy clients), so > far without success. > > I've read different things, on the one hand Ubuntu has removed > TLSv1/TLSv1.1 support completely, otherwise that it can be enabled: > http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.1.1f-1ubuntu2/changelog > > > Is there anything that can be set in HAProxy? (apart from > "ssl-default-bind-options ssl-min-ver TLSv1.0 ssl-max-ver TLSv1.2") > > Has anybody more information on this matter or has TLSv1 working in Ubuntu > 20.04 + HAProxy? > > Best regards / Mit freundlichen Grüßen > Bjoern >
Ubuntu 20.04 + TLSv1
Hi, currently i'm testing Ubuntu 20.04 and HAProxy 2.0.14. I'm trying to get TLSv1 working (we need this for some legacy clients), so far without success. I've read different things, on the one hand Ubuntu has removed TLSv1/TLSv1.1 support completely, otherwise that it can be enabled: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.1.1f-1ubuntu2/changelog Is there anything that can be set in HAProxy? (apart from "ssl-default-bind-options ssl-min-ver TLSv1.0 ssl-max-ver TLSv1.2") Has anybody more information on this matter or has TLSv1 working in Ubuntu 20.04 + HAProxy? Best regards / Mit freundlichen Grüßen Bjoern
Re: Patch backport request: __USE_GNU breaks uclibc in the 2.1 branch
On Fri, Jun 12, 2020 at 12:54:26PM +0200, Chris wrote: > http://git.haproxy.org/?p=haproxy.git;a=commit;h=62af9c83f9ed2b25e0061798e29e3cccfce5fbdc). > > So in conclusion, my request is to backport Willy's change to the 2.1 > tree, please. > Hello Chris, I just backported it and pushed it in the 2.1 git. Regards, -- William Lallemand
Patch backport request: __USE_GNU breaks uclibc in the 2.1 branch
Hello everybody,
I am one of the maintainers of the haproxy package for the OpenWRT
project. I am reaching out to you because - as of HAProxy version
2.1.5 - we experience build-issues on some of our build-targets.
We mostly use MUSL and uclibc as our c-libraries because they are more
suitable for embedded devices which are our main focus. Since HAProxy
version 2.1.5, the build is broken for all of our uclibc-targets:
src/standard.c: In function 'dladdr_and_size':
src/standard.c:4356:8: warning: implicit declaration of function
'dladdr1'; did you mean 'dladdr'? [-Wimplicit-function-declaration]
ret = dladdr1(addr, dli, (void **), RTLD_DL_SYMENT);
^~~
dladdr
src/standard.c:4356:42: error: 'RTLD_DL_SYMENT' undeclared (first use
in this function); did you mean 'DT_SYMENT'?
ret = dladdr1(addr, dli, (void **), RTLD_DL_SYMENT);
^~
DT_SYMENT
src/standard.c:4356:42: note: each undeclared identifier is reported
only once for each function it appears in
The problem lies in the #ifdef in src/standard.c:
static int dladdr_and_size(const void *addr, Dl_info *dli, size_t *size)
{
int ret;
#ifdef __USE_GNU // most detailed one
const ElfW(Sym) *sym;
ret = dladdr1(addr, dli, (void **), RTLD_DL_SYMENT);
if (ret)
*size = sym ? sym->st_size : 0;
#else
ret = dladdr(addr, dli);
*size = 0;
#endif
return ret;
}
Neither MUSL nor uclibc support dladdr1() so both must fall back to
using dladdr(). However, __USE_GNU is defined in uclibc making it use
dladdr1() resulting in the compilation failure. Using __USE_GNU is
generally not recommended so I wrote a patch which changed the #ifdef
to check for GLIBC. When I was preparing for submitting the patch for
the haproxy dev-branch I realized that Willy already did basically the
exact same thing there (here:
http://git.haproxy.org/?p=haproxy.git;a=commit;h=62af9c83f9ed2b25e0061798e29e3cccfce5fbdc).
So in conclusion, my request is to backport Willy's change to the 2.1
tree, please.
Thanks a lot,
Christian
Re: missing backports in haproxy-1.8
On Fri, Jun 12, 2020 at 11:10:08AM +0200, William Lallemand wrote: > I pushed them in the 1.8 git. I couldn't reproduce the issue though, > which compiler do you use? > I ran into the issue with gcc 10.1.0. Thanks for the backports! Jérôme
Re: missing backports in haproxy-1.8
On Thu, Jun 11, 2020 at 07:47:32PM +0200, Jerome Magnin wrote: > On Thu, Jun 11, 2020 at 07:27:26PM +0200, William Lallemand wrote: > > On Thu, Jun 11, 2020 at 12:41:51PM +0200, Jerome Magnin wrote: > > > 72d9f3351 BUILD: chunk: properly declare pool_head_trash as extern > > > 2231b6388 BUILD: cache: avoid a build warning with some compilers/linkers > > > > > The 1.8 didn't receive any new backports since the 1.8.25 release, but I > > take notes of these two, thanks! > > > Hi William, > > I thought they might have been forgotten because they are supposed to be > backported as far as 1.9 as per commit message, but I needed them to > build 1.8 today. > > Jérôme I pushed them in the 1.8 git. I couldn't reproduce the issue though, which compiler do you use? -- William Lallemand
Re: dev 2.2 High CPU Constantly
Hi, are those log lines both in syslog? I didn't see it there. I'm using this simple setup for a forward HTTP proxy, sooner and later, CPU goes crazy. On Fri, Jun 12, 2020 at 12:24 AM William Dauchy wrote: > > Hello Igor, > > On Thu, Jun 11, 2020 at 5:25 PM Igor Pav wrote: > > We got a very high CPU constantly while using 2.2dev. Any suggestion? > > Thanks. > > Do you have more inputs of what you are doing to trigger that? > does it end at some point with an abort? e.g do you have in logs > things like "Thread X is about to kill the process". If so could you > provide the full logs of the error? > or do you have logs starting with "A bogus STREAM" -> in that case it > can be related to what we are currently looking at in > https://github.com/haproxy/haproxy/issues/662 > > Thanks, > -- > William
