RE: Latest 2.8-dev not doing TLS 1.2
Shawn, >From: Shawn Heisey >Sent: Friday, May 19, 2023 3:33 PM > >I have a config that I have had in place for a while now. It did TLS >1.2 and 1.3, and got an A+ rating at SSL Labs. > >Today I was running the SSL test again and it only got an A rating >instead of A+. Looking deeper at the results, I saw that it was no >longer doing TLS 1.2 ... only TLS 1.3. > >Below are the global section, the defaults section, the bind lines from >the frontend, and haproxy -vv output. If there is something missing >that would shine a light on the issue, please let me know. > >I haven't changed any TLS-related config for a LONG time now. Is there >something I am doing wrong that has disabled TLS 1.2 in 2.8-dev? ... >HAProxy version 2.8-dev12-ffdf6a-1 2023/05/17 ... >Built with OpenSSL version : OpenSSL 3.1.0+quic 14 Mar 2023 >Running on OpenSSL version : OpenSSL 3.1.0+quic 14 Mar 2023 FWIW, I just tested 2.8-dev12-f48b23f (one commit behind yours, which is a doc patch) with statically linked quictls 3.0.8+quic (not 3.1.0+quic like yours, so could be relevant) and the following TLS-related configuration bits. Got A+ and both TLS v1.2 and v1.3 working (sorry, long lines): ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 ssl-default-bind-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 ssl-default-bind-options no-tls-tickets ssl-min-ver TLSv1.2 # Don't think this affects TLSv1.2, just here for completeness tune.ssl.default-dh-param 2048 I'd suggest you try with ssl-default-bind-options as in my config, and maybe ssl-default-bind-ciphers as well as these are for TLS
Reproducible ERR_QUIC_PROTOCOL_ERROR with all QUIC-enabled versions (2.6 to latest 2.8-dev)
While experimenting with enabling QUIC in HAProxy sitting in front of our closed-source application I stumbled upon a reproducible QUIC protocol failure/malfunction while accessing specific CSS resource, which is served via internal application proxy: accessing it over QUIC results either in ERR_QUIC_PROTOCOL_FAILURE in the browser and no mention of request in HAProxy log or incomplete resource being download and CD-- request termination flags in HAProxy log (and logged request looks a bit different from other, successful, H3 requests). Accessing the same resource over HTTP/2 works fine. I need help with setting up a proper debug session so that I could capture all necessary information which may help with fixing this issue: HAProxy internal debugging/tracing flags to enable, etc. I don't want to open a bug on GitHub for this and would appreciate if anyone from HAProxy team could reach out to me directly so that I could share relevant information and attempt to debug under your direction. Thanks in advance, Vladimir "Bob" Zakharychev
RE: Question about http compression
>From: Emerson Gomes >Sent: Monday, February 21, 2022 2:46 PM >To: Tom Browder >Cc: HAProxy >Subject: Re: Question about http compression > >Hi, > >You're mixing up the concepts of TLS compression and HTTP compression. They >are different things. >Indeed TLS compression is not advised due to security concerns. > >However, this has nothing to do with HTTP compression, which is normally done >using gzip or brotli algorithms, and specified as "Content-Encoding" on the >HTTP header. Emerson, With all due respect, please read up on BREACH at the link Lukas Tribus provided in response to OP (https://breachattack.com) which attacks regular HTTP compression using techniques similar to CRIME attack against TLS compression. Unfortunately it is very much a thing and appears to be only completely mitigated by disabling HTTP compression of potentially vulnerable responses or, if this can't be determined, then all responses. Cheers, Bob
BoringSSL commit dddb60e breaks compilation of HAProxy
BoringSSL commit dddb60e, "Make most of crypto/x509 opaque.", breaks
compilation of HAProxy with the following errors (log from compiling HAProxy
2.4.4 with BoringSSL master branch commit a03c34c, but I suppose all other
versions are equally affected):
...
CC src/ssl_sample.o
In file included from include/haproxy/listener-t.h:37,
from include/haproxy/server-t.h:36,
from include/haproxy/lb_map-t.h:26,
from include/haproxy/backend-t.h:30,
from include/haproxy/proxy-t.h:35,
from include/haproxy/applet-t.h:31,
from include/haproxy/obj_type.h:26,
from src/ssl_sample.c:27:
include/haproxy/openssl-compat.h: In function 'X509_OBJECT_get0_X509_CRL':
include/haproxy/openssl-compat.h:182:23: error: dereferencing pointer to
incomplete type 'X509_OBJECT' {aka 'const struct x509_object_st'}
if (a == NULL || a->type != X509_LU_CRL) {
^~
src/ssl_sample.c: In function 'smp_fetch_ssl_x_key_alg':
include/haproxy/openssl-compat.h:122:37: error: dereferencing pointer to
incomplete type 'X509' {aka 'struct x509_st'}
#define X509_get_X509_PUBKEY(x) ((x)->cert_info->key)
^~
src/ssl_sample.c:716:55: note: in expansion of macro 'X509_get_X509_PUBKEY'
X509_PUBKEY_get0_param(, NULL, NULL, NULL,
X509_get_X509_PUBKEY(crt));
^~~~
make: *** [Makefile:945: src/ssl_sample.o] Error 1
Indeed, BoringSSL commit dddb60e "unexported" these structs "aligning with
OpenSSL" and directs to "Use the accessor APIs instead". I couldn't figure out
an easy fix to this - simply removing the two macros conditional on
OPENSSL_IS_BORINGSSL in affected places doesn't fully help because while
X509_get_X509_PUBKEY() accessor is now defined, X509_OBJECT_get0_X509_CRL() is
still missing in BoringSSL. Therefore I defer the fix to HAProxy SSL experts -
maybe it's actually BoringSSL that needs to be fixed by adding the missing
accessor, or maybe the single loop in ssl_set_cert_crl_file() over all X509
store objects needs to be broken into two loops: one over certs returned by
X509_STORE_get1_certs() and another over CRLs returned by
X509_STORE_get1_crls().
Thanks in advance for taking a stab at this,
Bob
RE: How to suppress weak ciphers
FWIW, here's what we use in production with HAProxy 2.1.4 statically linked with OpenSSL 1.1.1f, gives us an A rating with 90 score for cipher strength from SSLLabs test: # recommended modern ciphersuites. Qualys SSLLab reports some of them # as weak due to use of inferior CBC mode, but disabling them breaks # compatibility with quite a few browsers still in the wild. ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 # TLSv1.3 ciphersuites: for now, the same as OpenSSL default ssl-default-bind-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 # Disable TLSv1.1 and down and TLS tickets ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets Here's what they report for TLS 1.2: # TLS 1.2 (suites in server-preferred order) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519 (eq. 3072 bits RSA) FS256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)ECDH x25519 (eq. 3072 bits RSA) FS256(P) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA) FS128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 (P) This server prefers ChaCha20 suites with clients that don't have AES-NI (e.g., Android devices) Disabling the two weak ciphers knocks off too many browsers still in wide use, so we ruled against it. Bob -Original Message- From: Branitsky, Norman Sent: Wednesday, April 22, 2020 2:20 PM To: Jerome Magnin Cc: haproxy@formilux.org Subject: RE: How to suppress weak ciphers [Warning] This email comes from an external source. Be careful of any embedded links and attachments. As you can see from my pasted configuration, I was specifying exactly 4 ciphers. The 2 weak CBC ciphers were magically appearing in the SSL Labs report. I tried to explicitly delete them - but the delete request is ignored. It seems that this entry, for example, must actually be a family: ECDHE-RSA-AES256-SHA384 which includes ECDHE-RSA-AES256-CBC-SHA384 Not clear why the explicit delete command doesn't delete the CBC cipher. Do you use the following specification and do you find sufficient support of existing browsers? ssl-default-bind-ciphers CHACHA20:AESGCM:AESCCM:!RSA Or is this too aggressive? Norman Branitsky Senior Cloud Architect P: 416-916-1752 -Original Message- From: Jerome Magnin Sent: Wednesday, April 22, 2020 11:50 AM To: Branitsky, Norman Cc: haproxy@formilux.org Subject: Re: How to suppress weak ciphers Hi Norman, On Wed, Apr 22, 2020 at 03:29:28PM +, Branitsky, Norman wrote: > HA-Proxy version 1.7.10-a7dcc3b 2018/01/02 SSL Labs reports the CBC > ciphers are "weak": > > [cid:image002.jpg@01D6117D.1C8AC910] > > I've tried to explicitly negate these ciphers with an "!" in haproxy.cfg to > no avail: > > > ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 > no-tls-tickets > > ssl-default-bind-ciphers > ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES2 > 56-SHA384:ECDHE-RSA-AES128-SHA256:!ECDHE-RSA-AES256-CBC-SHA384:!ECDHE- > RSA-AES128-CBC-SHA384 > > ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 > no-tls-tickets > > ssl-default-server-ciphers > ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES2 > 56-SHA384:ECDHE-RSA-AES128-SHA256:!ECDHE-RSA-AES256-CBC-SHA384:!ECDHE- > RSA-AES128-CBC-SHA384 > > How do I delete the "weak" ciphers? > If you list all the ciphers you want to support, it does not make sense to negate those you don't want. just don't list them. You would use ! to exclude specific ciphers or ciphers "families", ie: ssl-default-bind-ciphers CHACHA20:AESGCM:AESCCM:!RSA you can find additional information on this in the manpage for ciphers(1). regards, Jérôme
RE: Mirror concepts
My crystal ball ain’t working either, so please be more specific. You need to provide at least two essential pieces of information for anyone to be able to help you, ideally three: 1. What you did? 2. What you got? 3. [optional, but highly recommended] What did you expect? In other words, show us your configs and your commands, tell us what you thought you’re going to achieve with them and show us your logs and errors which show what went wrong. Cheers, Bob From: Panneer Selvam Sent: Thursday, February 13, 2020 5:58 AM To: Aleksandar Lazic Cc: Haproxy@formilux.org Subject: Re: Mirror concepts My haproxy mirror concepts not working Thanks On Thursday, February 13, 2020, Aleksandar Lazic mailto:al-hapr...@none.at>> wrote: Hi. Feb 13, 2020 1:04:58 AM Panneer Selvam : > Hi I need quick helping for HAproxy mirroring concepts Please can you tell us a little bit more what you need and please answer to all, thanks. Have you read an understand the post? https://www.haproxy.com/blog/haproxy-traffic-mirroring-for-real-world-testing/ > Thanks Panneer Regards Aleks
RE: [PATCH] MINOR: lua: Add lua-prepend-path configuration option
I'd say that since the issue can be solved naturally and completely within the confines of Lua itself, new parameters should not be introduced in HAProxy to give one ability to solve it differently while obscuring the solution in configuration of the host program, however tempting this might look. Just my two cents. Bob -Original Message- From: Willy Tarreau Sent: Thursday, January 9, 2020 11:42 AM To: Tim Düsterhus Cc: Adis Nezirovic ; haproxy@formilux.org; tfourn...@arpalert.org Subject: Re: [PATCH] MINOR: lua: Add lua-prepend-path configuration option On Thu, Jan 09, 2020 at 03:00:34PM +0100, Tim Düsterhus wrote: > However this morning I started thinking whether it might make sense to > generalize `lua-prepend-path` to `lua-run-string` that would execute > the Lua script given as the parameter. It might provide better > flexibility and would be as readable as lua-prepend-path: > > lua-run-string "package.path = package.path .. ';/some/path/?.lua'" > > Opinions? I'm seeing some merit in this for quite some stuff which annoys us by requiring a dedicated file. I'm just a bit anxious about how this can steer from the original intent, with users seeing it as a way to inline code anywhere, then complaining that we don't have multi-line strings nor 64kB long lines :-/ I'm interested in other opinions on this as well. Willy
RE: haproxy 2.0.0 build openssl version mismatch?
rpath is not the best solution here IMO - if the dependency is moved or removed (or replaced with a wrong SO in the right path, maybe even maliciously) from the system haproxy will still fail to load. I personally simply statically link OpenSSL into the HAProxy executable, which makes it portable and independent of OS SO configuration or paths. In order to statically link OpenSSL, simply build it without shared library support (no-shared) and then relink haproxy against it with the same SSL_INC and SSL_LIB. If you still want to use rpath, I believe you can add it with ADDLIB variable: make TARGET=linux-glibc ... ADDLIB="-rpath /opt/prod/openssl111c/lib64" Bob -Original Message- From: hal...@xsmail.com Sent: Wednesday, July 17, 2019 12:32 PM To: Aleksandar Lazic Cc: Zakharychev, Bob ; haproxy@formilux.org Subject: Re: haproxy 2.0.0 build openssl version mismatch? On Wed, Jul 17, 2019, at 9:13 AM, Aleksandar Lazic wrote: > > Can you try to adopt your system to the openssl path as I in the dockerfile. > > https://gitlab.com/aleks001/haproxy20-centos/blob/master/Dockerfile#L3 > 7 > > ``` > echo "/opt/prod/openssl111c/lib64" > > /etc/ld.so.conf.d/openssl-111c.conf \ && ldconfig -v \ ``` ldconfig additions/changes are system-wide, and local environment specific -- and subject to end-user override. does haproxy simply support rpath -- which correctly solves the linking problem in the distributed package by hardcoding the specified/intended runtine path -- like most other packages? e.g., all rpath'd &/or config-managed build/installs, ldd `which nginx` | egrep "ssl|crypto" libssl.so.1.1 => /opt/prod/openssl111c/lib64/libssl.so.1.1 (0x7f24ae9f6000) libcrypto.so.1.1 => /opt/prod/openssl111c/lib64/libcrypto.so.1.1 (0x7f24ae4f) ldd `which php` | egrep "ssl|crypto" libssl.so.1.1 => /opt/prod/openssl111c/lib64/libssl.so.1.1 (0x7f4c1533a000) libcrypto.so.1.1 => /opt/prod/openssl111c/lib64/libcrypto.so.1.1 (0x7f4c14e34000) ldd `which mariadb` | egrep "ssl|crypto" libssl.so.1.1 => /opt/prod/openssl111c/lib64/libssl.so.1.1 (0x7feb8998a000) libcrypto.so.1.1 => /opt/prod/openssl111c/lib64/libcrypto.so.1.1 (0x7feb89484000) ldd `which named` | egrep "ssl|crypto" libssl.so.1.1 => /opt/prod/openssl111c/lib64/libssl.so.1.1 (0x7f539d468000) libcrypto.so.1.1 => /opt/prod/openssl111c/lib64/libcrypto.so.1.1 (0x7f539cf62000) ldd `which openvpn` | egrep "ssl|crypto" libssl.so.1.1 => /opt/prod/openssl111c/lib64/libssl.so.1.1 (0x7fd1d891b000) libcrypto.so.1.1 => /opt/prod/openssl111c/lib64/libcrypto.so.1.1 (0x7fd1d8415000) ldd `which curl` | egrep "ssl|crypto" libssl.so.1.1 => /opt/prod/openssl111c/lib64/libssl.so.1.1 (0x7f5085647000) libcrypto.so.1.1 => /opt/prod/openssl111c/lib64/libcrypto.so.1.1 (0x7f5085149000) etc etc none of which need ldconfig.
RE: haproxy 2.0.0 build openssl version mismatch?
Unless you statically link OpenSSL, haproxy will attempt to load default OS SOs on startup. Obviously, haproxy was compiled with OpenSSL 1.1.1c, but default SOs are not. You should add your OpenSSL 1.1.1c SO directory to, say, /etc/ld.so.conf.d/ossl111c.conf file (or whatever else you choose to name it as long as it's .conf) and run ldconfig to load the updated configuration. You can use "ldd haproxy" to verify SO dependencies and how they are resolved. Bob -Original Message- From: hal...@xsmail.com Sent: Wednesday, July 17, 2019 11:39 AM To: Zakharychev, Bob ; haproxy@formilux.org Subject: Re: haproxy 2.0.0 build openssl version mismatch? bob On Wed, Jul 17, 2019, at 8:29 AM, Zakharychev, Bob wrote: > you are using SSL_INC and SSL_LIB incorrectly: they should ONLY > contain paths to corresponding include and library directories, not > GCC options. So in your case they should look like this: > > SSL_LIB=/opt/prod/openssl111c/lib64 \ > SSL_INC=/opt/prod/openssl111c/include \ switching to make V=1 \ TARGET=linux-glibc \ USE_SYSTEMD=1 \ USE_PCRE2=1 \ USE_PCRE2_JIT=1 \ USE_OPENSSL=1 \ SSL_LIB=/opt/prod/openssl111c/lib64 \ SSL_INC=/opt/prod/openssl111c/include \ USE_THREAD=1 \ USE_PTHREAD_PSHARED=1 \ USE_TFO=1 \ USE_NS=1 now, after build, /opt/prod/haproxy/sbin/haproxy -vv /opt/prod/haproxy/sbin/haproxy: /usr/lib64/libssl.so.1.1: version `OPENSSL_1_1_1' not found (required by /opt/prod/haproxy/sbin/haproxy) /opt/prod/haproxy/sbin/haproxy: /usr/lib64/libcrypto.so.1.1: version `OPENSSL_1_1_1' not found (required by /opt/prod/haproxy/sbin/haproxy) it completely ignores the specified paths, and incorrectly links the distro-installed, system libs. hal
RE: haproxy 2.0.0 build openssl version mismatch?
hal, you are using SSL_INC and SSL_LIB incorrectly: they should ONLY contain paths to corresponding include and library directories, not GCC options. So in your case they should look like this: SSL_LIB=/opt/prod/openssl111c/lib64 \ SSL_INC=/opt/prod/openssl111c/include \ Hth, Bob -Original Message- From: hal...@xsmail.com Sent: Wednesday, July 17, 2019 11:15 AM To: haproxy@formilux.org Subject: haproxy 2.0.0 build openssl version mismatch? I'm building haproxy 2.0.0, ... setting ssl flags to use that local instance, with rpath, haproxy build has no errors make V=1 \ TARGET=linux-glibc \ USE_SYSTEMD=1 \ USE_PCRE2=1 \ USE_PCRE2_JIT=1 \ USE_OPENSSL=1 \ SSL_LIB=" -L/opt/prod/openssl111c/lib64 -Wl,-rpath,/opt/prod/openssl111c/lib64" \ << wrong! SSL_INC=" -I/opt/prod/openssl111c/include" \ << wrong! USE_THREAD=1 \ USE_PTHREAD_PSHARED=1 \ USE_TFO=1 \ USE_NS=1 hal
RE: cygwin compilation error
Willy, > > Looks like it decided that non-letter characters had to be encoded. > > We're using FD_ISSET() to look up the characters in the character > > encoding map because this was convenient in the past, but maybe it's > > time to have a native implementation of a bit address lookup and get rid of > > this now. > > I've just created an issue about this one so we don't forget it. > > Willy FWIW: after a bit of experimentation and a quick dumb behavior comparison program I found that FD_SET is compiled incorrectly by GCC 8.3.0 under Cygwin with optimization level of -O2 and up. I compared native FD_SET/FD_ISSET with hap_fd_set/hap_fd_isset and while the latter always functions correctly, the former broke with -O2 and beyond. Further playing with optimizations enabled by -O2 I was able to narrow the offender down to -ftree-pre, which enables partial redundancy elimination (PRE) on trees. When tree PRE is enabled, GCC generates wrong code for inlined FD_SET in map initialization loop which results in most, and eventually all, bits of the map set when they shouldn't, which explains those superfluous escapes that caused reg-tests failures. When compiled with -fno-tree-pre, most reg-tests now pass. Still, since there is already native implementation of bit address lookup and it seems to work correctly with all optimizations enabled, maybe it's better just to switch to it. Bob
RE: cygwin compilation error
>On Tue, Jun 04, 2019 at 09:46:04PM +0000, Zakharychev, Bob wrote: >> I mean it returns 0. What happens is that as soon as the other side >> (haproxy) terminates, poll() starts returning immediately with >> positive return value and POLLIN being the only flag set in >> fd->revents as if there's something to read and descriptor is still open. >> read() then returns 0. Rinse, repeat. > >OK so this is a valid detection of end of response. > >> Since original VTest code only breaks the poll/read loop if either >> POLLHUP or POLLERR are also set in revents, which doesn't happen here >> for some reason, > > You should see POLLHUP and POLLERR as optimizations : when the system already > knows there will be such events it may place them, but similarly they could > also > happen between the moment you check the events and the moment you decide > to read, so really a read() should always check for error and for zero. Thanks for the explanation. I was under impression I'm missing something obvious here, but if this is expected behavior then I guess my workaround is not really a workaround. >> the loop never breaks until the thread itself times out (10 seconds) >> and gets killed. This, however, results in a "failed" test from VTest >> perspective. I think I can #ifdef __CYGWIN__ my changes to keep >> original behavior intact where it's known to work. > I'd say "s/is known to work/happens to work/" :-) Probably that an issue > should be > filed on this specific point for vtest to improve it (and its portability). > After all, nothing > prevents poll() from being implemented using select() and it should work in > this situation. Looking at Cygwin poll() source code it's actually the way it's implemented: using cygwin_select(), which seems to be a wrapper around pselect(). I'll suggest my patch to vtest. Bob
RE: cygwin compilation error
Willy, On Tue, Jun 04, 2019 at 05:52:12PM +, Zakharychev, Bob wrote: >> Finally got VTest compiling and working as expected (I think) under Cygwin. >> config.h had to be adjusted and vtc_syslog.c needed >> included, but nothing big. However, there's some weird poll() behavior >> where it never raises POLLHUP or POLLERR and returns immediately with >> POLLIN flag raised when the other side disconnects but read() >> consistently returns no error and no data, > Note, by "no error and no data", do you mean "-1, EAGAIN" or "0" ? Because > the only case read() should return zero is when the end was reached. POLLHUP > is not even guaranteed to be presented at all. That's why most of the time you > see POLLHUP|POLLIN registered for the same handler. I mean it returns 0. What happens is that as soon as the other side (haproxy) terminates, poll() starts returning immediately with positive return value and POLLIN being the only flag set in fd->revents as if there's something to read and descriptor is still open. read() then returns 0. Rinse, repeat. Since original VTest code only breaks the poll/read loop if either POLLHUP or POLLERR are also set in revents, which doesn't happen here for some reason, the loop never breaks until the thread itself times out (10 seconds) and gets killed. This, however, results in a "failed" test from VTest perspective. I think I can #ifdef __CYGWIN__ my changes to keep original behavior intact where it's known to work. >> so when haproxy gets killed vtc_record() keeps polling its STDOUT >> until the thread itself times out because poll() doesn't seem to >> return correct flags. >> >> I hacked vtc_record() to exit the loop when poll() returns with POLLIN >> raised, but read() returns 0 bytes two times in a row. This got most >> of the reg-tests running successfully. Now some of them fail because >> the expected syslog format doesn't match what HA-Proxy actually logs: >> >> Slog_1 0.2 syslog|<6>127.0.0.1:61336 [04/Jun/2019:12:56:28.053] >> ssl-offload-http~ ssl-offload-http/http 0/0/-1/-1/0 503 220 - - SC-- >> 1/1/0/0/3 0/0 "POST#20#2F#31#20HTTP#2F#31#2E#31" >> ** Slog_1 0.2 === expect ~ "ssl-offload-http/http .* \"POST /[1-8] >> HTTP/(2\\.0... >> Slog_1 0.2 EXPECT FAILED ~ "ssl-offload-http/http .* "POST /[1-8] >> HTTP/(2\.0|1\.1)"" > Looks like it decided that non-letter characters had to be encoded. We're > using FD_ISSET() > to look up the characters in the character encoding map because this was > convenient in > the past, but maybe it's time to have a native implementation of a bit > address lookup and > get rid of this now. > Good job! > Willy Thanks Bob
RE: cygwin compilation error
Finally got VTest compiling and working as expected (I think) under Cygwin.
config.h had to be adjusted and vtc_syslog.c needed included,
but nothing big. However, there’s some weird poll() behavior where it never
raises POLLHUP or POLLERR and returns immediately with POLLIN flag raised when
the other side disconnects but read() consistently returns no error and no
data, so when haproxy gets killed vtc_record() keeps polling its STDOUT until
the thread itself times out because poll() doesn’t seem to return correct flags.
I hacked vtc_record() to exit the loop when poll() returns with POLLIN raised,
but read() returns 0 bytes two times in a row. This got most of the reg-tests
running successfully. Now some of them fail because the expected syslog format
doesn’t match what HA-Proxy actually logs:
Slog_1 0.2 syslog|<6>127.0.0.1:61336 [04/Jun/2019:12:56:28.053]
ssl-offload-http~ ssl-offload-http/http 0/0/-1/-1/0 503 220 - - SC-- 1/1/0/0/3
0/0 "POST#20#2F#31#20HTTP#2F#31#2E#31"
** Slog_1 0.2 === expect ~ "ssl-offload-http/http .* \"POST /[1-8]
HTTP/(2\\.0...
Slog_1 0.2 EXPECT FAILED ~ "ssl-offload-http/http .* "POST /[1-8]
HTTP/(2\.0|1\.1)""
or
S 0.2 syslog|<134>Jun 4 13:40:59 haproxy[49078]: 127.0.0.1:62880
[04/Jun/2019:13:40:59.348] fe be/srv 0/0/0/34/34 200 17477 - - 1/1/0/0/0
0/0 {#48#50#68#78#38#6E#35#39#71#6A#6A#4E#42#4C#6A#50}
{#68#74#62#35#36#71#44#64#43#63#62#52#56#54#66#53}
"GET#20#2F#20HTTP#2F#31#2E#31"
** S 0.2 === expect ~ "[^:\\[ ]\\[${h_pid}\\]: .* .* fe be/srv .* 200
1[0...
S 0.2 EXPECT FAILED ~ "[^:\[ ]\[49078\]: .* .* fe be/srv .* 200
1[0-9]{4} - - .* .* {HPhx8n59qjjNBLjP} {htb56qDdCcbRVTfS} "GET /
HTTP/1\.1""
I’ve no idea why it logs literals encoded like this and what should be changed
in log configuration or maybe in build options to get it logging in expected
format.
Bob
From: Илья Шипицин
Sent: Monday, June 3, 2019 4:21 PM
To: Zakharychev, Bob
Cc: HAProxy
Subject: Re: cygwin compilation error
btw, Bob, can you run reg-tests on cygwin ? maybe you can prepare travis-ci
config for cygwin ?
вт, 4 июн. 2019 г. в 00:57, Zakharychev, Bob
mailto:bob.zakharyc...@spirent.com>>:
Ilya,
FWIW: I tried to build 2.0-dev5 on my working copy of Cygwin-64 3.0.7 with GCC
toolchain 8.3.0 running just
make TARGET=cygwin
and it compiled successfully, but initially didn’t link due to
src/mux_h2.o: In function `h2s_frt_make_resp_data':
/build/haproxy-2.0-dev5/src/mux_h2.c:4405: undefined reference to `trace'
/build/haproxy-2.0-dev5/src/mux_h2.c:4405:(.text+0xce79): relocation truncated
to fit: R_X86_64_PC32 against undefined symbol `trace'
collect2: error: ld returned 1 exit status
make: *** [Makefile:821: haproxy] Error 1
I think this is due to lack of support for weak function attribute in the
Cygwin GCC linker – one comment about USE_OBSOLETE_LINKER in the code seems to
be mentioning this as well. I added a crude workaround and successfully linked
the executable with it. Here’s the patch, maybe you folks can improve it or
just accept it as is. It just uses the TRACE flag and conditionally defines the
dummy trace() in standard.c if the flag is not present (which is essentially
the same as having the linker override a weak function).
diff -uw a/src/standard.c b/src/standard.c
--- a/src/standard.c 2019-06-02 06:06:08.0 -0400
+++ b/src/standard.c 2019-06-03 14:23:15.437931700 -0400
@@ -4298,10 +4298,12 @@
}
/* do nothing, just a placeholder for debugging calls, the real one is in
trace.c */
-__attribute__((weak,format(printf, 1, 2)))
+#ifndef TRACE
+__attribute__((format(printf, 1, 2)))
void trace(char *msg, ...)
{
}
+#endif
/*
* Local variables:
I also ran into a linker warning when building with Lua support:
/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/bin/ld:
warning: --export-dynamic is not supported for PE+ targets, did you mean
--export-all-symbols?
I was able to get rid of it with the following modification to the Makefile
(what the warning suggested):
diff -uw a/Makefile b/Makefile
--- a/Makefile 2019-06-02 06:06:08.0 -0400
+++ b/Makefile 2019-06-03 14:48:47.098917100 -0400
@@ -406,6 +406,8 @@
USE_POLL USE_TPROXY USE_OBSOLETE_LINKER)
# Cygwin adds IPv6 support only in version 1.7 (in beta right now).
TARGET_CFLAGS = $(if $(filter 1.5.%, $(shell uname -r)), -DUSE_IPV6
-DAF_INET6=23 -DINET6_ADDRSTRLEN=46, )
+ # --export-dynamic is not the right way to export symbols in Cygwin
+ EXPORT_SYMBOL = --export-all-symbols
endif
# set the default settings according to the target above
Other than these two rather small issues 2.0-dev5 built successfully on my
Cygwin (and I then also successfully built it with threading support, PCRE,
ZLib, OpenSSL and Lua 5.3 by enabling corresponding flags though I didn’t run
any tests), so something must be miss
RE: cygwin compilation error
Ilya, Try pulling in gcc-core libgcc1 binutils. I can’t actually see how it’s compiling without a compiler :), but worth trying. Also, check output from cpp -v /dev/null -o /dev/null This should print the search path – we can then verify that /usr/include and other dirs are in it. Bob From: Илья Шипицин Sent: Monday, June 3, 2019 4:09 PM To: Zakharychev, Bob Cc: HAProxy Subject: Re: cygwin compilation error I use the following command to build environment: https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L10 "poll.h" is located in /usr/include https://travis-ci.com/chipitsine/haproxy/builds/114162585#L231
RE: cygwin compilation error
Ilya,
FWIW: I tried to build 2.0-dev5 on my working copy of Cygwin-64 3.0.7 with GCC
toolchain 8.3.0 running just
make TARGET=cygwin
and it compiled successfully, but initially didn’t link due to
src/mux_h2.o: In function `h2s_frt_make_resp_data':
/build/haproxy-2.0-dev5/src/mux_h2.c:4405: undefined reference to `trace'
/build/haproxy-2.0-dev5/src/mux_h2.c:4405:(.text+0xce79): relocation truncated
to fit: R_X86_64_PC32 against undefined symbol `trace'
collect2: error: ld returned 1 exit status
make: *** [Makefile:821: haproxy] Error 1
I think this is due to lack of support for weak function attribute in the
Cygwin GCC linker – one comment about USE_OBSOLETE_LINKER in the code seems to
be mentioning this as well. I added a crude workaround and successfully linked
the executable with it. Here’s the patch, maybe you folks can improve it or
just accept it as is. It just uses the TRACE flag and conditionally defines the
dummy trace() in standard.c if the flag is not present (which is essentially
the same as having the linker override a weak function).
diff -uw a/src/standard.c b/src/standard.c
--- a/src/standard.c 2019-06-02 06:06:08.0 -0400
+++ b/src/standard.c 2019-06-03 14:23:15.437931700 -0400
@@ -4298,10 +4298,12 @@
}
/* do nothing, just a placeholder for debugging calls, the real one is in
trace.c */
-__attribute__((weak,format(printf, 1, 2)))
+#ifndef TRACE
+__attribute__((format(printf, 1, 2)))
void trace(char *msg, ...)
{
}
+#endif
/*
* Local variables:
I also ran into a linker warning when building with Lua support:
/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/bin/ld:
warning: --export-dynamic is not supported for PE+ targets, did you mean
--export-all-symbols?
I was able to get rid of it with the following modification to the Makefile
(what the warning suggested):
diff -uw a/Makefile b/Makefile
--- a/Makefile 2019-06-02 06:06:08.0 -0400
+++ b/Makefile 2019-06-03 14:48:47.098917100 -0400
@@ -406,6 +406,8 @@
USE_POLL USE_TPROXY USE_OBSOLETE_LINKER)
# Cygwin adds IPv6 support only in version 1.7 (in beta right now).
TARGET_CFLAGS = $(if $(filter 1.5.%, $(shell uname -r)), -DUSE_IPV6
-DAF_INET6=23 -DINET6_ADDRSTRLEN=46, )
+ # --export-dynamic is not the right way to export symbols in Cygwin
+ EXPORT_SYMBOL = --export-all-symbols
endif
# set the default settings according to the target above
Other than these two rather small issues 2.0-dev5 built successfully on my
Cygwin (and I then also successfully built it with threading support, PCRE,
ZLib, OpenSSL and Lua 5.3 by enabling corresponding flags though I didn’t run
any tests), so something must be missing in your build environment. Most system
headers should be in /usr/include if cygwin-devel is installed, so you might
want to start with checking if expected header files are there…
Hth,
Bob
From: Илья Шипицин
Sent: Monday, June 3, 2019 11:03 AM
To: Gil Bahat
Cc: Willy Tarreau ; HAProxy
Subject: Re: cygwin compilation error
пн, 3 июн. 2019 г. в 20:00, Gil Bahat
mailto:bahat@gmail.com>>:
poll.h seems to be present at cygwin-devel:
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=poll.h=x86_64
hope that helps.
cygwin-devel is installed
https://travis-ci.com/chipitsine/haproxy/builds/114061737#L165-L172
Regards,
Gil
On Mon, Jun 3, 2019 at 5:53 PM Илья Шипицин
mailto:chipits...@gmail.com>> wrote:
пн, 3 июн. 2019 г. в 17:56, Willy Tarreau mailto:w...@1wt.eu>>:
Hi Ilya,
On Mon, Jun 03, 2019 at 01:57:48PM +0500, ??? wrote:
> Hello, Gil Bahat!
>
> can you help with troubleshooting?
>
> I created some basic cygwin CI:
>
> https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30
>
> it fails with
>
> src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory
> #include
> ^~~~
> compilation terminated.
> make: *** [Makefile:830: src/ev_poll.o] Error 1
>
> (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 )
>
> do you know which package does "poll.h" belongs to ?
Interesting, maybe poll() should be disabled on cygwin and we'd only
keep select ? (just build with "USE_POLL=" for this).
I'll try that.
Actually, I think that I need to install some missing cygwin package
(I installed very few of them using "choco install bash make openssl-devel
cygwin-devel --source cygwin")
Willy
RE: cygwin compilation error
Ilya Shipitsin wrote on Wed, 08 May 2019 03:22:20 -0700: >I guess the same would be with BoringSSL. It exposes OPENSSL_VERSION_NUMBER >and it is not openssl itself. > >yes, we can add warning. I wouldn't bother even trying to add support for BoringSSL - they themselves discourage people from doing so in their mission statement: "Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability. Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you." Regards, Bob
