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 inc
Willy,
>
> Fred told me that he manages to build it using the fork of openssl that
> contains the proper stuff. Hopefully it should get merged soon. But with
> BoringSSL the problem is that something that works on monday suddenly
> fails to build on tuesday and there's no stable branch so you're
>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 s
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
ER
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 r
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
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
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 doi
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: und
: Илья Шипицин
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
http
\.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: cygw
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(
>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
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
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,
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
:
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 versio
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 loo
18 matches
Mail list logo