Re: [ANNOUNCE] haproxy-2.5-dev10

2021-10-18 Thread William Lallemand
On Sat, Oct 16, 2021 at 04:22:29PM +0200, Willy Tarreau wrote:
>
> Hi,
> 
> HAProxy 2.5-dev10 was released on 2021/10/16. It added 75 new commits
> after version 2.5-dev9.
> 
> The smoke is progressively being blown away and we're starting to see
> clearer what final 2.5 will look like.
> 
> In completely random order, here are the main changes I noticed in this
> release:
> 
>   - some fixes for OpenSSL 3.0.0 support from Rémi and William; regression
> tests were fixed as well and the version in the CI was upgraded from
> alpha17 to 3.0.0

What's important to mention is that we don't have broken SSL reg-tests
anymore, which is probably the first time since we introduced the
reg-tests, lot of them was broken because of incompatibilities with
previous OpenSSL version, or LibreSSL/boringSSL.

Regarding the whole reg-tests directory, only 3 remains broken:

reg-tests$ git grep REGTEST_TYPE=broken .
connection/proxy_protocol_random_fail.vtc:#REGTEST_TYPE=broken
mailers/healthcheckmail.vtc:#REGTEST_TYPE=broken
seamless-reload/abns_socket.vtc:#REGTEST_TYPE=broken

> 
>   - William added a new config predicate "ssllib_name_startswith" to
> detect the type of SSL library in "-cc" rules.

Actually it's Rémi's patches. It completes the "openssl_version_atleast"
predicate that was previously done and allow us to be very precise in
the test selection, which was not the case before.

-- 
William Lallemand



Re: question: ExecStartPre removal from systemd unit file

2021-08-19 Thread William Lallemand
Hi Tim,

On Thu, Aug 19, 2021 at 12:22:25PM +0200, Tim Düsterhus wrote:
> 
> The config check should prevent HAProxy from going into wait mode when 
> the config is bad on a reload. If I am not mistaken it's not possible to 
> recover from wait mode without a full restart, no?
> 

Well, this line is not used for the reload, but only for the start. For
the reload the first ExecReload line is used:

ExecReload=@SBINDIR@/haproxy -Ws -f $CONFIG -c -q $EXTRAOPTS
ExecReload=/bin/kill -USR2 $MAINPID
 
The purpose of this reload line is only to return a status code to
systemd during a reload, because kill can't achieve that. It's not
really a problem to be in "wait" mode, if you do a reload again with a
working configuration it will be in a normal state. The wait mode is
just a state where the master only supervise the previous workers and
couldn't fork new workers.

-- 
William Lallemand



question: ExecStartPre removal from systemd unit file

2021-08-19 Thread William Lallemand
Hi List,

I realized yesterday that we have this line in the systemd unit file:

ExecStartPre=@SBINDIR@/haproxy -f $CONFIG -c -q $EXTRAOPTS

Which does not make any sense to me since starting HAProxy itself
checks the configuration, so it slows the start of the service for
nothing.

I'm going to remove this line.

Is there anyone against it, or did I miss a particular usecase?

Thanks,

-- 
William Lallemand



Re: [ANNOUNCE] haproxy-2.5-dev3

2021-08-02 Thread William Lallemand
Hello,

On Sun, Aug 01, 2021 at 06:28:27PM +0200, Willy Tarreau wrote:
>   - a new option "httpslog" was added to complement "httplog". It aims at
> providing some info about the TLS frontend connection by default, such
> as the ciphers used and errors met etc. It is also possible to disable
> low-level SSL error reports to only use these ones (and this should be
> the long-term direction to take). A few sample fetch functions were
> added to extract the SSL-level info. I'm aware that the thread on this
> subject is still active, and any feedback is welcome if that helps to
> further improve the situation for users.
> 

We need feedback about this, it will probably change in the future, the
github thread is available here:

https://github.com/haproxy/haproxy/issues/693

Don't hesitate to report your problems or needs in the ticket.

-- 
William Lallemand



Re: no-stop keyword proposal

2021-07-27 Thread William Lallemand
On Tue, Jul 20, 2021 at 12:18:18PM -0300, Joao Morais wrote:
> Subject: no-stop keyword proposal
>
> 
> Hello list, the diff below is a proposal to add a bind keyword used to
> flag LI_O_NOSTOP option in the bind’s listener.
> 
> Regarding the use case: I need the ability to reach a stopping, but
> still running haproxy instance to, at least:
> 1) fairly distribute
> shutdown sessions of long running connections (usually websockets)
> before hard-stop-after timeouts and kicks all the remaining
> connections at the same time[1]; 2) collect some relevant metrics from
> a stopping instance, e.g. current sessions and rps, which would be
> otherwise lost when these metrics are collected only from the current
> instance.
> 

This is already possible using the master CLI, it was done to access all
processes, old and new. It was designed to do that kind of things.


> Regarding the patch: it’s just the changes I needed to make and
> confirm that it works like I was expecting, provided that the
> listening socket is changed before reloading haproxy into a new
> instance. Please let me know if such improvement can be made and also
> if I’m in the right path.
> 
> ~jm
> 
> [1] https://www.mail-archive.com/haproxy@formilux.org/msg40916.html
> 
> diff --git a/src/cli.c b/src/cli.c
> index b3132191d..4285e5a72 100644
> --- a/src/cli.c
> +++ b/src/cli.c
> @@ -1841,6 +1841,19 @@ static int bind_parse_level(char **args, int cur_arg, 
> struct proxy *px, struct b
>   return 0;
>  }
> 
> +/* parse the "no-stop" bind keyword */
> +static int bind_parse_no_stop(char **args, int cur_arg, struct proxy *px, 
> struct bind_conf *conf, char **err)
> +{
> + struct listener *l;
> +
> + list_for_each_entry(l, >listeners, by_bind) {
> + l->options |= LI_O_NOSTOP;
> + HA_ATOMIC_INC(_jobs);
> + }
> +
> + return 0;
> +}
> +
>  static int bind_parse_severity_output(char **args, int cur_arg, struct proxy 
> *px, struct bind_conf *conf, char **err)
>  {
>   if (!*args[cur_arg + 1]) {
> @@ -2984,6 +2997,7 @@ INITCALL1(STG_REGISTER, cfg_register_keywords, 
> _kws);
>  static struct bind_kw_list bind_kws = { "STAT", { }, {
>   { "level", bind_parse_level,1 }, /* set the unix socket admin 
> level */
>   { "expose-fd", bind_parse_expose_fd, 1 }, /* set the unix socket expose 
> fd rights */
> + { "no-stop",   bind_parse_no_stop, 0 }, /* flag LI_O_NOSTOP in the 
> listener options */
>   { "severity-output", bind_parse_severity_output, 1 }, /* set the 
> severity output format */
>   { NULL, NULL, 0 },
>  }};
> 
> 

That's not a good idea in my opinion, it's an internal state that should
be used only in the case of communication between the master and the
workers, if we expose this to users we will probably have a lot of
corner cases to handle.
This keyword is only meant to say to a worker that it must keep the
communication with the master even if it's trying to exit, so we could
do some maintenance or debugging over the master CLI.

-- 
William Lallemand



Re: Proposal about new default SSL log format

2021-07-08 Thread William Lallemand
On Thu, Jul 08, 2021 at 02:48:32PM +0200, Willy Tarreau wrote:
> On Thu, Jul 08, 2021 at 02:18:32PM +0200, William Lallemand wrote:
> > I saw that you hesitated between "conn_status" and "conn_err_code", the
> > "conn_" prefix could be confusing at some point once you try to have
> > errors on the frontend and the backend side in the same log-format, I
> > think something starting by "fc_conn_" would be more understandable.
> 
> Indeed, and more consistent with what we already have. fc_* is for the
> front connection, bc_* is for the back connection. By the way if we're
> focusing on SSL it should even be ssl_fc_* (we already have a ton of
> them, nobody will find the new one if it doesn't use the same prefix).
>

That's what Rémi implemented for the SSL fetches, but the connection
error one is more generic and does not focus on SSL at all.

> > That seems good to me, we only need frontend info IMHO. People who need
> > the SSL backend connection are not the most common case so they could
> > make their own log-format with it.
> 
> I tend to think that if we're focusing on https vs http, it makes sense
> to consider the frontend only as well for the standard logs.
>

I agree.

> Also some background on the log format, originally we used to place the
> URI at the end of the line because most loggers used to truncate logs
> at 1024 bytes and the tail of the URI was far less important than other
> fields. This explains why we've started to insert certain fields at
> certain places before this. 20 years later I think it is perfectly
> reasonable to consider appending fields *after* the URI, which is also
> a great way of applying minimal changes to existing log parsers, and
> to allow http/https log lines to be easily compared when aligned.
> 

I agree, this way it's easily readable without having to realign
mentally the fields in common between an http line and an https one.


-- 
William Lallemand



Re: Proposal about new default SSL log format

2021-07-08 Thread William Lallemand
Hello,

On Wed, Jul 07, 2021 at 04:43:53PM +0200, Remi Tricot-Le Breton wrote:
> I was indeed more focused on logging SSL related information only, with 
> the idea that an SSL log line could be displayed after a completed 
> handshake, hence the lack of upper layer information in the log line. 
> But it would indeed bring a new level of complexity in the log because 
> correlating the SSL and HTTP log lines of a specific session might be a 
> pain. After talking with Willy, an https log was deemed more useful. It 
> would only be an extension of the existing HTTP log with SSL specific 
> information added. This log format would concern every log line raised 
> by the frontends using this log format (one line per HTTP response of 
> the SSL session).

Yes, what would be great is a "option httpslog" which would provide a
default log line for HTTP over SSL.

> A quick recap of the topics raised by the multiple conversations had in 
> this thread :
> - we won't used tabs as separators in order to remain consistent with 
> the existing log format (especially since this new format will only be 
> an extension of the HTTP one)

I agree, using tab doesn't not seems to be something we would want, it's
the same problem with people that would want json in their log, they
need a new format, not the default one.

> - the date format won't change right now, it is a whole new subject
> - the logged lines will all have the same "date+process_name+pid" prefix 
> as the already existing logs
> - the HTTP log format won't be touched yet, changing it would be a whole 
> new subject as well

Agreed.

> 
> 
> The log would then be as follows :
> 
> 
>      >>> Jul  1 18:11:31 haproxy[143338]: 127.0.0.1:37740 
> [01/Jul/2021:18:11:31.517] \
>    ssl_frontend~ ssl_frontend/s2 0/0/0/7/+7 200 2750 - -  \
>    1/1/1/1/0 0/0 {1wt.eu} {} "GET /index.html HTTP/1.1 \
>    0/0/0/0 TLSv1.3/TLS_AES_256_GCM_SHA384
> 
>    Field   Format    Extract from the 
> example above
>    1   process_name '[' pid ']:' haproxy[143338]:
>    2   client_ip ':' client_port 127.0.0.1:37740
>    3   '[' request_date ']' [01/Jul/2021:18:11:31.517]
>    4   frontend_name ssl_frontend~
>    5   backend_name '/' server_name ssl_frontend/s2
>    6   TR '/' Tw '/' Tc '/' Tr '/' Ta*   
> 0/0/0/7/+7
>    7 status_code 200
>    8 bytes_read* 2750
>    9 captured_request_cookie -
>   10 captured_response_cookie -
>   11 termination_state 
>   12   actconn '/' feconn '/' beconn '/' srv_conn '/' retries*    
> 1/1/1/1/0
>   13   srv_queue '/' 
> backend_queue  0/0
>   14   '{' captured_request_headers* '}' {haproxy.1wt.eu}
>   15   '{' captured_response_headers* 
> '}'    {}
>   16   '"' http_request '"'  "GET /index.html 
> HTTP/1.1"
>   17 *conn_status '/' SSL fe hsk error '/' SSL vfy '/' SSL CA vfy*  
> 0/0/0/0
>   18 *ssl_version '/' ssl_ciphers* TLSv1.3/TLS_AES_256_GCM_SHA384
> 
> and the corresponding log-format :
> 
>      %ci:%cp [%tr] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta %ST %B %CC \
>      %CS %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r \
> *%[conn_err_code]/%[ssl_fc_hsk_err]/%[ssl_c_err]/%[ssl_c_ca_err]* \
> *%sslv/%sslc*
> 

I saw that you hesitated between "conn_status" and "conn_err_code", the
"conn_" prefix could be confusing at some point once you try to have
errors on the frontend and the backend side in the same log-format, I
think something starting by "fc_conn_" would be more understandable.

That seems good to me, we only need frontend info IMHO. People who need
the SSL backend connection are not the most common case so they could
make their own log-format with it.


-- 
William Lallemand



Re: Speeding up opentracing build in CI ?

2021-06-17 Thread William Lallemand
On Thu, Jun 17, 2021 at 03:53:10PM +0200, Willy Tarreau wrote:
> Subject: Re: Speeding up opentracing build in CI ?
>
> On Thu, Jun 17, 2021 at 03:29:58PM +0200, Willy Tarreau wrote:
> > On Thu, Jun 17, 2021 at 03:24:19PM +0200, Willy Tarreau wrote:
> > > On Thu, Jun 10, 2021 at 08:55:13PM +0500,  ??? wrote:
> > > > I was mistaken. LibreSSL does not like parallel install
> > > > 
> > > > libressl fails on `make -j4 install` · Issue #461 ·
> > > > libressl-portable/portable (github.com)
> > > > <https://github.com/libressl-portable/portable/issues/461>
> > > > 
> > > > 
> > > > anyway, if CI works, I'm ok with changes
> > > 
> > > OK I've applied the change to use build_sw on openssl only (libressl
> > > doesn't have it), and -j$(nproc) for this phase for openssl on linux
> > > (will likely be 2). Let's see.
> > 
> > Hmmm it fails with 1.0.2, there's no build_sw there. In addition I do
> > remember that 1.0.2 used to require significant patches to be reliable
> > under make -j.
> > 
> > Let's wait for the remaining tests to conclude.
> 
> OK that's a net win, openssl-3.0.0-alpha17 dropped from 8'29 to 2'55.
> I've just excluded versions 1.x from both the parallel build and the
> build_sw target and that's good now.
> 
> Willy

Great improvement, thanks!

-- 
William Lallemand



Re: [PATCH] CI: cirrus: add alpine linux to the jobs

2021-06-14 Thread William Lallemand
On Mon, Jun 14, 2021 at 12:01:11PM +0200, Tim Düsterhus wrote:
> We only run Travis once weekly, because of the limited credits we have. 
> Thus only the newest commit at time of running will have a Travis CI 
> Status integrated into GitHub.
> 
> The most recent one is this: 
> https://github.com/haproxy/haproxy/commit/1b095cac9468d0c3eeb157e9b1a2947487bd3c83


I thought it disappeared completely from the interface, good to know!

Thanks

-- 
William Lallemand



Re: [PATCH 0/4] Use 'feature cmd' in regtests

2021-06-14 Thread William Lallemand
On Mon, Jun 14, 2021 at 02:03:55PM +0200, Willy Tarreau wrote:
> On Mon, Jun 14, 2021 at 03:49:05PM +0500,  ??? wrote:
> > I believe William means conditions like "openssl is 1.1.0 or higher", but
> > that's possible using grep
>

I agree, there are cases when you would want (OPENSSL_VERSION > 0.9.8 &&
OPENSSL_VERSION < 1.1.0) for example, we were limited in the past by
that. Maybe that could be done with grep but honestly that's
over-complicated and poorly readable.

It's not really the case anymore because we stopped to test with
CentOS 6 on the CI but we could have that kind of problem again. 

> And anyway I do want to add config predicates that will provide this.
> As I said when I added a few of them for ".if", the main use will be
> vtc, and we should not waste our time, and just add what is missing.
> 

Looks like a good idea imho, it could even be used to provide several
kind of regex depending of which regex library you use for example.

-- 
William Lallemand



Re: [PATCH 0/4] Use 'feature cmd' in regtests

2021-06-14 Thread William Lallemand
On Fri, Jun 11, 2021 at 07:56:14PM +0200, Tim Duesterhus wrote:
> Hi!
> 

Hello Tim,

> I hope I added all the active developers that touch the reg-tests to the 'CC'
> list :-)
> 
> This series updates the regtests to make use of VTest's 'feature cmd' syntax
> to skip tests that are not supported in the current environment.
> 
> In the long run this will should result in much cleaner tests, because they
> don't need to be parsed by run-regtests.sh to extract these marker comments. 
> It
> also allows to easily add test specific requirements without needing to invent
> an entirely new syntax. An example might be the recently added tests that are
> not supported on BoringSSL. These should be able to get a condition like:
> 
> feature cmd "$HAPROXY_PROGRAM -vv |grep -vq BoringSSL"
> 
> and then they won't run for BoringSSL (the example is untested).
> 

That's very interesting, I had a discussion with Willy last week about
this kind of problems. I think that's clearly the cleanest soluton to
the problem.

In my opinion it only lacks a way to check the OpenSSL version from
'haproxy -cc' so we can enable ssl/set_ssl_cert_bundle.vtc again.


> After this series is applied the output of 'make reg-tests' will change. Tests
> that are excluded using 'feature cmd' will still be listed as "Add test" in
> the test gathering section. However the final line will show that a few tests
> have been skipped:
> 
> 0 tests failed, 4 tests skipped, 105 tests passed
> 
> I don't think this is going to be an issue. But if it is, please complain!
>

Hm the only problem I have with this, is that we won't be able to see why a
test was excluded.

-- 
William Lallemand



Re: [PATCH] CI: cirrus: add alpine linux to the jobs

2021-06-14 Thread William Lallemand
On Sat, Jun 12, 2021 at 03:47:46PM +0500, Илья Шипицин wrote:
>
> final apline/musl patch attached
> 

Thanks Ilya, I thought it will be more hackish but it's clean and
simple!

Also it looks like we can build/test several architectures by combining
the same technique  with the qemu docker image (
https://github.com/docker/setup-qemu-action )

I just remembered that we had travis-ci to achieve that in the past, but
it looks like it's not integrated in the github interface, I don't
remember why. https://travis-ci.com/github/haproxy/haproxy It looks like
it's still running though.

According to their documentation they are running the CI
on the actual CPU not a emulated one, so still beter than qemu.

-- 
William Lallemand



Re: [PATCH] CI: cirrus: add alpine linux to the jobs

2021-06-11 Thread William Lallemand
On Fri, Jun 11, 2021 at 08:14:49PM +0500, Илья Шипицин wrote:
> I've found ubuntu musl package, so we can just link to it in CI, for
> example (I'll try)
> 


Well, that won't give you the same environnement as a docker image,
with the same versions. I'll honestly prefer if we could do it with the
alpine image.

I you want to build with the musl-gcc wrapper you will need to link the
linux headers in the musl headers directory otherwise it won't work the
way their package is done.

-- 
William Lallemand



Re: [PATCH] CI: cirrus: add alpine linux to the jobs

2021-06-11 Thread William Lallemand
On Fri, Jun 11, 2021 at 07:09:14PM +0500, Илья Шипицин wrote:
> I'm against expanding cirrus matrix. cirrus is overloaded already, I'm
> afraid they will not stay for long time.
> using custom images in github actions is straightforward, have a look
> 
> centos 6 · chipitsine/haproxy@20fabcd (github.com)
> <https://github.com/chipitsine/haproxy/commit/20fabcd005dc9e3bac54a84bf44631f177fa79c2>
> 
> 
> the same way you can specify either alpine or even special prepared image.
> as I recall last time, we decided not to add alpine because "it is tested
> anyway when docker images are created"
>

As far as I know, it is only built, not tested. We encountered a few
problems that could have been caught before being built by Docker.
And that will prevent us to release a version that doesn't work
correctly with docker before they are built on the docker hub. 


> also, there's small caveat, github actions runs agent inside docker
> container, it might have issues with older libc (or musl).
> but it worth a try
> 

Let's hope it works in this case.


-- 
William Lallemand



Re: [PATCH] CI: cirrus: add alpine linux to the jobs

2021-06-11 Thread William Lallemand
On Fri, Jun 11, 2021 at 07:19:51PM +0500, Илья Шипицин wrote:
> William, if you do not have a time, I can try to create github action based
> on your cirrus patch ... tomorrow ?
> 

I tried quickly but like Tim I couldn't make it work.

I can't spend much time on this, if you are able to make this work I
prefer to run it from github actions, otherwise we'll go with cirrus.

Thanks,

-- 
William Lallemand



[PATCH] CI: cirrus: add alpine linux to the jobs

2021-06-11 Thread William Lallemand
This commit adds a CI job to cirrus-ci which builds HAProxy on Alpine
Linux, allowing to build and test HAProxy with musl.

OpenSSL, PCRE2, Lua 5.3 as well as the prometheus exporter are enabled.

GNU grep was purposely installed to run the reg-test script.
---
 .cirrus.yml | 13 +
 1 file changed, 13 insertions(+)

diff --git a/.cirrus.yml b/.cirrus.yml
index 9b83e6169..392a3abc5 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -11,3 +11,16 @@ FreeBSD_task:
 - ./haproxy -vv
 - ldd haproxy
 - env VTEST_PROGRAM=../vtest/vtest gmake reg-tests 
REGTESTS_TYPES=default,bug,devel || (for folder in /tmp/*regtest*/vtc.*; do cat 
$folder/INFO $folder/LOG; done && exit 1)
+
+alpine_task:
+  container:
+image: alpine:latest
+  only_if: $CIRRUS_BRANCH =~ 'master|next'
+  script:
+- apk add gcc make tar git python3 libc-dev linux-headers pcre-dev 
pcre2-dev openssl-dev lua5.3-dev grep socat curl
+- git clone https://github.com/VTest/VTest.git ../vtest
+- make -C ../vtest FLAGS="-O2 -s -Wall"
+- make CC=cc V=1 TARGET=linux-musl USE_LUA=1 LUA_INC=/usr/include/lua5.3 
LUA_LIB=/usr/lib/lua5.3 USE_OPENSSL=1 USE_PCRE2=1 USE_PCRE2_JIT=1 USE_PROMEX=1
+- ./haproxy -vv
+- ldd haproxy
+- env VTEST_PROGRAM=../vtest/vtest make reg-tests 
REGTESTS_TYPES=default,bug,devel || (for folder in /tmp/*regtest*/vtc.*; do cat 
$folder/INFO $folder/LOG; done && exit 1)
-- 
2.17.1




add alpine linux to the CI

2021-06-11 Thread William Lallemand
Hello guys,

I couldn't find a way to launch an alpine job easily with github actions so
instead I wrote one for cirrus-ci, It will help debugging Docker images
and musl problems.

Example of the run here: https://cirrus-ci.com/task/5985082050609152

I'll push it in the master if that's fine with you.





Re: Speeding up opentracing build in CI ?

2021-06-10 Thread William Lallemand
On Thu, Jun 10, 2021 at 07:52:23AM +0200, Willy Tarreau wrote:
> Subject: Re: Speeding up opentracing build in CI ?
>
> On Thu, Jun 10, 2021 at 07:19:37AM +0200, Willy Tarreau wrote:
> > On Thu, Jun 10, 2021 at 10:15:46AM +0500,  ??? wrote:
> > > OT takes about 30 sec (it is built with almost everything disabled). the
> > > biggest time eater is openssl-3.0.0
> > 
> > Maybe that one could be sped up too, I haven't checked if it uses parallel
> > builds.
> 
> So I checked. Good news, it wasn't parallel either, and this alone:
> 
> --- a/scripts/build-ssl.sh
> +++ b/scripts/build-ssl.sh
> @@ -21,7 +21,8 @@ build_openssl_linux () {
>  (
>  cd "openssl-${OPENSSL_VERSION}/"
>  ./config shared --prefix="${HOME}/opt" --openssldir="${HOME}/opt" 
> -DPURIFY
> -make all install_sw
> +make -j$(nproc) all
> +make install_sw
>  )
>  }
> 
> Is enough to drop from 4:52 to 1:28 on my machine. About 1/4 of this time
> is used to build man and HTML pages that we don't use. Instead of the "all"
> target, we should use "build_sw"
> 
> --- a/scripts/build-ssl.sh
> +++ b/scripts/build-ssl.sh
> @@ -21,7 +21,8 @@ build_openssl_linux () {
>  (
>  cd "openssl-${OPENSSL_VERSION}/"
>  ./config shared --prefix="${HOME}/opt" --openssldir="${HOME}/opt" 
> -DPURIFY
> -make all install_sw
> +make -j$(nproc) build_sw
> +make install_sw
>  )
>  }
> 
> this further downs the time to 1:9, hence more than 4 times faster than
> the initial one. It should probably be tested on macos to be certain it's
> OK there as well, and I don't know how to get the CPU count there (or
> maybe we could just force it to a low value like 2 or 4).
> 
> Willy
> 

Looks fine to me, but from what I remember when debugging some reg-tests
there was only one CPU available, I hope I'm wrong.

-- 
William Lallemand



Re: [PATCH] CI: enable openssl-3.0.0 builds

2021-06-07 Thread William Lallemand
On Mon, Jun 07, 2021 at 02:17:24PM +0200, William Lallemand wrote:
>
> On Mon, Jun 07, 2021 at 02:09:33PM +0200, Tim Düsterhus wrote:
> >
> > William,
> > 
> > On 6/7/21 1:30 PM, William Lallemand wrote:
> > > On Mon, Jun 07, 2021 at 04:02:00PM +0500, Илья Шипицин wrote:
> > >> sorry, I do not have much spare time to implement that in short time
> > >> perspective.
> > >> I think of 2-3 month timeframe.
> > >>
> > > 
> > > Isn't it possible to pass a make argument for one specific CI job?
> > > 
> > > This way we could just do something like:
> > > 
> > >make DEBUG_CFLAGS="-g -Wno-deprecated-declarations"
> > > 
> > 
> > Yes, this would be possible. It's already done to enable QUIC for BoringSSL:
> > 
> > https://github.com/haproxy/haproxy/blob/a9334df5a9bee2bf17b22f965b08df8d47f2f63e/.github/matrix.py#L116-L117
> > 
> > It would need an extra case for OpenSSL 3. You can test whether it works 
> > locally using:
> > 
> > $ python3 .github/matrix.py push
> > 
> > Best regards
> > Tim Düsterhus
> 
> Looks easy enough, I'll try that, thanks.
> 

It worked:

https://github.com/haproxy/haproxy/runs/2764512334

Thanks,

-- 
William Lallemand



Re: [PATCH] CI: enable openssl-3.0.0 builds

2021-06-07 Thread William Lallemand
On Mon, Jun 07, 2021 at 02:09:33PM +0200, Tim Düsterhus wrote:
> Subject: Re: [PATCH] CI: enable openssl-3.0.0 builds
>
> William,
> 
> On 6/7/21 1:30 PM, William Lallemand wrote:
> > On Mon, Jun 07, 2021 at 04:02:00PM +0500, Илья Шипицин wrote:
> >> sorry, I do not have much spare time to implement that in short time
> >> perspective.
> >> I think of 2-3 month timeframe.
> >>
> > 
> > Isn't it possible to pass a make argument for one specific CI job?
> > 
> > This way we could just do something like:
> > 
> >make DEBUG_CFLAGS="-g -Wno-deprecated-declarations"
> > 
> 
> Yes, this would be possible. It's already done to enable QUIC for BoringSSL:
> 
> https://github.com/haproxy/haproxy/blob/a9334df5a9bee2bf17b22f965b08df8d47f2f63e/.github/matrix.py#L116-L117
> 
> It would need an extra case for OpenSSL 3. You can test whether it works 
> locally using:
> 
> $ python3 .github/matrix.py push
> 
> Best regards
> Tim Düsterhus

Looks easy enough, I'll try that, thanks.

-- 
William Lallemand



Re: [PATCH] CI: enable openssl-3.0.0 builds

2021-06-07 Thread William Lallemand
On Mon, Jun 07, 2021 at 05:08:32PM +0500, Илья Шипицин wrote:
> пн, 7 июн. 2021 г. в 16:31, William Lallemand :
> 
> > On Mon, Jun 07, 2021 at 04:02:00PM +0500, Илья Шипицин wrote:
> > > sorry, I do not have much spare time to implement that in short time
> > > perspective.
> > > I think of 2-3 month timeframe.
> > >
> >
> > Isn't it possible to pass a make argument for one specific CI job?
> >
> > This way we could just do something like:
> >
> >   make DEBUG_CFLAGS="-g -Wno-deprecated-declarations"
> >
> 
> please send a patch
> 

Sorry if I wasn't clear but this was a question. I have no idea how this
works and you are the more experienced with Tim on this subject :-)

-- 
William Lallemand



Re: [PATCH] CI: enable openssl-3.0.0 builds

2021-06-07 Thread William Lallemand
On Mon, Jun 07, 2021 at 04:02:00PM +0500, Илья Шипицин wrote:
> sorry, I do not have much spare time to implement that in short time
> perspective.
> I think of 2-3 month timeframe.
> 

Isn't it possible to pass a make argument for one specific CI job?

This way we could just do something like:

  make DEBUG_CFLAGS="-g -Wno-deprecated-declarations"

-- 
William Lallemand



Re: [PATCH] CI: enable openssl-3.0.0 builds

2021-06-07 Thread William Lallemand
On Sun, Jun 06, 2021 at 05:36:45AM +0200, Willy Tarreau wrote:
> On Sun, Jun 06, 2021 at 12:51:53AM +0200, Tim Düsterhus wrote:
> > Ilya,
> > 
> > On 6/5/21 5:10 AM,  ??? wrote:
> > > here are two patches:
> > > 
> > > - deprecated warnings suppressed
> > > - openssl-3.0.0 enabled
> > > 
> > 
> > In the second patch you forgot the 'CI:' prefix in the commit message.
> > 
> > Other than that the patches LGTM with regard to the CI changes.
> 
> OK thanks Tim, I'll take it and adjust the subject.
> 
> Willy
> 

Hello,

I don't think that's a good idea to do it this way, the first intent was
to be able to build OpenSSL 3.0.0, but the -Wdeprecated-declarations was
preventing to build with -Werror.

With this patch we are hiding all these warnings for all users and they
can be relevant at some point, not only for OpenSSL, but for the other
libs that are linked with haproxy.

In my opinion we should only disable them for this specific build of
OpenSSL 3.0.0 on the CI, not for everyone in the Makefile.

-- 
William Lallemand



Re: [PATCH] CI: enable openssl-3.0.0 builds

2021-06-02 Thread William Lallemand
On Wed, Jun 02, 2021 at 04:34:16PM +0500, Илья Шипицин wrote:
> Subject: Re: [PATCH] CI: enable openssl-3.0.0 builds
>
> ср, 2 июн. 2021 г. в 16:27, Tim Düsterhus :
> 
> > Ilya,
> >
> > On 6/2/21 12:58 PM, Илья Шипицин wrote:
> > > as openssl-3.0.0 is getting close to release, let us add it to build
> > matrix.
> > >
> >
> > I dislike that this is going to report all commits in red, until the
> > build failures with OpenSSL 3 are fixed.

I agree, but in my opinion we should do it in two steps:

* fix the *errors* and build without -Werror in order to see the
  -Wdeprecated-declarations warnings.

* port haproxy to the new API (long term goal) to be able to build
  with openssl 3.0.0 with -Werror.


> 
> @William Lallemand   has an appetite to make it
> green ;)
> 

I'll fix what I can to be able to build with
-Wno-deprecated-declarations.

> I did a quick research, whether
> > some job could be marked as "experimental" / "allowed failure" with
> > GitHub Actions, but could not find anything.
> >

I don't think we need this, fixing the build errors shouldn't be long,
Emeric already made some tests with openssl3 few weeks ago and it was
working fine.

-- 
William Lallemand



Re: [PATCH] CI: switch to the latest stable LibreSSL-3.3.3

2021-05-05 Thread William Lallemand
On Wed, May 05, 2021 at 09:11:08AM +0500, Илья Шипицин wrote:
> Hello,
> 
> LibreSSL-3.3.3 just released. patch attached.
> 
> thanks,
> Ilya

Thanks, pushed in master.



-- 
William Lallemand



Re: Proposal about libslz integration into haproxy

2021-04-21 Thread William Lallemand
Hello,

On Wed, Apr 21, 2021 at 08:04:08AM +0200, Willy Tarreau wrote:
> [...]
> 
> So after changing my mind, I would go with the following approach:
> 
>   - building with USE_SLZ=1  => always use the embedded one
>   - building with USE_ZLIB=1 => always build using the user-provided zlib
> 
> We'd enable USE_SLZ by default and it would be disabled when ZLIB is used
> (or when SLZ is forced off). This way we could have fast and memory-less
> compression available by default without the hassle of cloning an unknown
> repository.
> 

That looks good to me, however I think it's better to disable SLZ
manually when building with zlib so we can emit an error when both
options are disabled, this way people are encouraged to migrate and will
think twice before setting USE_ZLIB. The disadvantage is that it would
break existing compilation line, but it's for a new major release so
it's fine in my opinion.

-- 
William Lallemand



[ANNOUNCE] haproxy-2.2.13

2021-04-02 Thread William Lallemand
Hi,

HAProxy 2.2.13 was released on 2021/04/02. It added 2 new commits
after version 2.2.12.

This version is released shortly after the 2.2.12 because a regression was
found. Indeed, people using multi-certificates bundle are not able to
start haproxy anymore, this does not happen if you use separate certificates
in your configuration. This regression is 2.2 only.

The multi-certificates bundle is an old feature which was implemented for old
version of OpenSSL to achieve ECDSA + RSA on the same bind line, with new
versions of OpenSSL it is not required anymore.

A lot of people are still using this feature, but it is recommended to migrate
to separate crt keywords in your configuration if you have at least OpenSSL
1.1.0, you can even have per-certificate configuration using a crt-list which
was not possible with a multi-certificates bundle.

As usual, it is strongly encouraged to update to this version.

#
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
   Wiki : https://github.com/haproxy/wiki/wiki
   Sources  : http://www.haproxy.org/download/2.2/src/
   Git repository   : http://git.haproxy.org/git/haproxy-2.2.git/
   Git Web browsing : http://git.haproxy.org/?p=haproxy-2.2.git
   Changelog: http://www.haproxy.org/download/2.2/src/CHANGELOG
   Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/


---
Complete changelog :
William Lallemand (2):
  BUG/MEDIUM: ssl: ckch_inst->ctx not assigned with multi-bundle 
certificates
  REGTESTS: ssl: "set ssl cert" and multi-certificates bundle

---

-- 
William Lallemand



Re: 2.2.12 and rsa/ecdsa cert regression (crash on startup) ?

2021-04-01 Thread William Lallemand
On Thu, Apr 01, 2021 at 02:26:07PM +0200, William Lallemand wrote:
> On Thu, Apr 01, 2021 at 10:19:31AM +, Jarno Huuskonen wrote:
> > Hello,
> > 
> > I'm seeing a regression with 2.2.12 and using rsa and ecdsa certs on bind.
> > (cert1.pem.ecdsa
> > cert1.pem.ecdsa.ocsp
> > cert1.pem.ocsp
> > cert1.pem.rsa
> > cert1.pem.rsa.ocsp
> > )
> > 
> 
> Thanks for the report, I can reproduce the problem, I'm investigating.
> 

Could you try the attached patch?

Thanks

-- 
William Lallemand
>From 3adeb8baf45c2f775848770b349cfa5e3fdd561b Mon Sep 17 00:00:00 2001
From: William Lallemand 
Date: Thu, 1 Apr 2021 15:48:21 +0200
Subject: [PATCH] BUG/MEDIUM: ssl: ckch_inst->ctx not assigned with
 multi-bundle certificates

When backporting patch 8218aed ("BUG/MINOR: ssl: Fix update of default
certificate") in 2.2, a regression was introduced. The 2.2
multi-certificate loading code does not have the same code path and this
part was not modified, introducing a segfault when trying to start
haproxy with a multi-certificate bundle.

This patch fixes the problem by setting the ckch_inst->ctx variable in
ckch_inst_new_load_multi_store().

No backport needed, 2.2 only.
---
 src/ssl_sock.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 14311370f3..627de34761 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -3340,9 +3340,16 @@ int ckch_inst_new_load_multi_store(const char *path, struct ckch_store *ckchs,
 
 
 	/* Mark a default context if none exists, using the ctx that has the most shared keys */
-	if (!bind_conf->default_ctx) {
-		for (i = SSL_SOCK_POSSIBLE_KT_COMBOS - 1; i >= 0; i--) {
-			if (key_combos[i].ctx) {
+	for (i = SSL_SOCK_POSSIBLE_KT_COMBOS - 1; i >= 0; i--) {
+		if (key_combos[i].ctx) {
+			if (!ckch_inst->ctx) {
+/* Always keep a reference to the newly constructed SSL_CTX in the
+ * instance. This way if the instance has no SNIs, the SSL_CTX will
+ * still be linked. */
+SSL_CTX_up_ref(key_combos[i].ctx);
+ckch_inst->ctx = key_combos[i].ctx;
+			}
+			if (!bind_conf->default_ctx) {
 bind_conf->default_ctx = key_combos[i].ctx;
 bind_conf->default_ssl_conf = ssl_conf;
 ckch_inst->is_default = 1;
-- 
2.26.3



Re: 2.2.12 and rsa/ecdsa cert regression (crash on startup) ?

2021-04-01 Thread William Lallemand
On Thu, Apr 01, 2021 at 10:19:31AM +, Jarno Huuskonen wrote:
> Hello,
> 
> I'm seeing a regression with 2.2.12 and using rsa and ecdsa certs on bind.
> (cert1.pem.ecdsa
> cert1.pem.ecdsa.ocsp
> cert1.pem.ocsp
> cert1.pem.rsa
> cert1.pem.rsa.ocsp
> )
> 

Thanks for the report, I can reproduce the problem, I'm investigating.


-- 
William Lallemand



Re: [PATCH] BUILD: ssl: use EVP_CIPH_GCM_MODE macro instead of HA_OPENSSL_VERSION

2021-03-26 Thread William Lallemand
On Fri, Mar 26, 2021 at 11:47:48PM +0500, Илья Шипицин wrote:
> Hello,
> 
> yet another patch that removes few HA_OPENSSL_VERSION usage.
> 
> Ilya

Pushed in master, thanks.

-- 
William Lallemand



Re: [PATCH] fine guard for ssl random extraction functions

2021-03-26 Thread William Lallemand
On Thu, Mar 25, 2021 at 12:52:42AM +0500, Илья Шипицин wrote:
> Hello,
> 
> yet another patch that removes several occurrences of HA_OPENSSL_VERSION
> also, fetches enabled for BoringSSL and LibreSSL-2.7.0 and higher
> 
> Ilya


Looks good, pushed in master, thanks!

-- 
William Lallemand



Re: [PATCH] fine guard for ssl random extraction functions

2021-03-26 Thread William Lallemand
On Fri, Mar 26, 2021 at 03:02:27PM +0100, Willy Tarreau wrote:
> On Fri, Mar 26, 2021 at 06:45:22PM +0500,  ??? wrote:
> > Ping :)
> 
> Ilya, please use the MAINTAINERS file to be sure to direct your messages
> to the relevant maintainers, because each time you forward them to me, I
> forward them in turn and the integration of your work gets needlessly
> delayed.

I agree. You can also wait more than 1 day before doing a "ping" for a
minor patch, it's more likely that we didn't read it yet than we missed
it.

> @Emeric, @William, could one of you please have a look ?
> 

I'll take a look.

-- 
William Lallemand



Re: Fwd: [PATCH] cleanup unused definitions

2021-03-24 Thread William Lallemand
On Wed, Mar 24, 2021 at 08:09:05AM +0100, Willy Tarreau wrote:
> William,
> 
> could you please have a quick look at these ? I didn't touch them because
> I don't know if these are things you intend to use in the short-to-mid
> term. If you take them, please be careful to fix the subject to mention
> "ssl" in them.
> 
> Thanks,
> Willy
> 
> - Forwarded message from  ???  -
> 
> > Date: Wed, 24 Mar 2021 11:29:03 +0500
> > From:  ??? 
> > Subject: Re: [PATCH] cleanup unused definitions
> > To: HAProxy , Willy Tarreau 
> > Delivered-To: haproxy@formilux.org
> > List-Id: Haproxy 
> > 
> > ping
> > 
> > ??, 20 ???. 2021 ?. ? 22:43,  ??? :
> > 
> > > while refactoring HA_OPENSSL_VERSION usage,
> > > I've found unused definitions. nice.
> > >
> > >
> > > Ilya
> > >
> 
> - End forwarded message -
> - Forwarded message from  ???  -
> 
> > Date: Wed, 24 Mar 2021 11:29:19 +0500
> > From:  ??? 
> > Subject: Re: [PATCH] BUILD: ssl: use feature guard instead of openssl 
> > version for ecdh functions
> > To: HAProxy , Willy Tarreau 
> > Delivered-To: haproxy@formilux.org
> > List-Id: Haproxy 
> > 
> > ping
> > 
> > ??, 21 ???. 2021 ?. ? 13:02,  ??? :
> > 
> > > Hello,
> > >
> > > yet another patch that reduces number of HA_OPENSSL_VERSION use
> > >
> > > Ilya
> > >
> > >
> > >
> 
> - End forwarded message -
> 

Thanks, both merged.

-- 
William Lallemand



Re: [PATCH] BUILD: ssl: use feature guard instead of openssl version for ecdh functions

2021-03-24 Thread William Lallemand
On Wed, Mar 24, 2021 at 11:29:19AM +0500, Илья Шипицин wrote:
> ping
> 
> вс, 21 мар. 2021 г. в 13:02, Илья Шипицин :
> 
> > Hello,
> >
> > yet another patch that reduces number of HA_OPENSSL_VERSION use
> >
> > Ilya
> >
> >
> >

Thanks, merged.

-- 
William Lallemand



Re: [PATCH] cleanup unused definitions

2021-03-24 Thread William Lallemand
On Wed, Mar 24, 2021 at 11:29:03AM +0500, Илья Шипицин wrote:
> ping
> 
> сб, 20 мар. 2021 г. в 22:43, Илья Шипицин :
> 
> > while refactoring HA_OPENSSL_VERSION usage,
> > I've found unused definitions. nice.
> >
> >
> > Ilya
> >

Thanks, merged.


-- 
William Lallemand



Re: is it possible to rotate TLS keys in scheduled way ?

2021-03-23 Thread William Lallemand
On Fri, Mar 19, 2021 at 09:50:29PM +0500, Илья Шипицин wrote:
> Hello,
> 
> can we have the following ?
> 
> 1) TLS tickets are persistent, i.e. they survive reload

There is no mecanism at the moment to pass memory from a process to
another one, it's a much larger problem that you have with statistics,
certificates, server state file etc.

The correct way to achieve this in the current state is to dump the file
from the CLI before reloading.

> 2) we can specify ttl of tickets

Hm that's an interesting idea but you can only store 3 tickets by
default a new ticket will need to be pushed each time a ticket expired.

-- 
William Lallemand



Re: [PATCH] BUG/MINOR: sample: Rename SenderComID/TargetComID to SenderCompID/TargetCompID

2021-03-10 Thread William Lallemand
On Wed, Mar 10, 2021 at 08:24:24AM +0100, Baptiste wrote:
> On Wed, Mar 10, 2021 at 5:15 AM Daniel Corbett  wrote:
> 
> > Hello,
> >
> >
> >
> >
> >
> > The recently introduced Financial Information eXchange (FIX)
> >
> > converters have some hard coded tags based on the specification that
> >
> > were misspelled. Specifically, SenderComID and TargetComID should
> >
> > be SenderCompID and TargetCompID according to the specification [1][2].
> >
> >
> >
> > This patch updates all references, which includes the converters
> >
> > themselves, the regression test, and the documentation.
> >
> >
> >
> > [1] https://fiximate.fixtrading.org/en/FIX.5.0SP2_EP264/tag49.html
> >
> > [2] https://fiximate.fixtrading.org/en/FIX.5.0SP2_EP264/tag56.html
> >
> >
> >
> >
> >
> >
> >
> > Thanks,
> >
> > -- Daniel
> >
> >
> >
> 
> Hi,
> 
> Thank you Daniel for reporting / fixing this.
> The patch looks correct and may be applied.
> 
> Baptiste

Thanks, applied.

-- 
William Lallemand



Re: [PATCH] BUILD: SSL: introduce fine guard for openssl specific "RAND_keep_random_devices_open"

2021-02-22 Thread William Lallemand
On Sat, Feb 20, 2021 at 12:06:35AM +0500, Илья Шипицин wrote:
> Hello,
> 
> another "get rid of HA_OPENSSL_VERSION" cleanup.
> 
> Ilya

> From 51b86c8b776b3462546a4037bf3a5022ccf6b709 Mon Sep 17 00:00:00 2001
> From: Ilya Shipitsin 
> Date: Fri, 19 Feb 2021 23:42:53 +0500
> Subject: [PATCH] BUILD: SSL: introduce fine guard for
>  RAND_keep_random_devices_open
> 
> RAND_keep_random_devices_open is OpenSSL specific function, not
> implemented in LibreSSL and BoringSSL. Let us define guard
> HAVE_SSL_RAND_KEEP_RANDOM_DEVICES_OPEN in include/haproxy/openssl-compat.h
> That guard does not depend anymore on HA_OPENSSL_VERSION


Thanks, merged!

-- 
William Lallemand



Re: [PATCH] introduce guard for SCTL openssl specific functions

2021-02-18 Thread William Lallemand
On Thu, Feb 18, 2021 at 07:06:14PM +0500, Илья Шипицин wrote:
> ping :)
> 
> On Sat, Feb 13, 2021, 11:48 AM Илья Шипицин  wrote:
> 
> > I changed macro name, new patch attached
> >

Merged, thanks.


-- 
William Lallemand



Re: [PATCH] introduce guard for SCTL openssl specific functions

2021-02-12 Thread William Lallemand
On Sat, Feb 13, 2021 at 12:21:56AM +0500, Илья Шипицин wrote:
> Hello,
> 
> let as switch to feature macro instead of HA_OPENSSL_VERSION.
> 
> Ilya

Hello Ilya,

For more concistency with the other macros I'd rather use
"HAVE_SSL_SCTL" instead of "HAVE_OPENSSL_SCTL".

Regards,

-- 
William Lallemand



Re: Should server crt be consider as crt-list and handled via the runtime API?

2021-02-08 Thread William Lallemand
On Mon, Feb 08, 2021 at 02:31:18PM +, Pierre Cheynier wrote:
> I'm trying to figure out what would be missing to consider server crt-s as 
> crt-lists (as in bind lines) so that they could be listed via "show ssl 
> crt-list" APIs and also managed (essentially renewed) this way.
> 
> Exemple:
>  backend foo-using-client-auth
>  default-server check ssl crt /path/to/crt-list ca-file /path/to/my/ca.pem
>  server srv0 192.0.2.1:80
> 
> I'd like then to manage this using:
>   set ssl cert  
> 
> The use-case being the following: when integrating with service mesh 
> solutions such as consul-connect, you may want to reduce the disruption 
> occurring when certificates are renewed.
> And in such kind of solution, they are renewed quite often (once every few 
> tens of hours).
> In this case the memory space is already allocated etc. so I (naively?) think 
> it probably doesn't hurt too much.
> 
> What is your point-of-view?
> 

Hello Pierre,

Thanks to Rémi development we already have the server crt update
available from the CLI in the 2.4 tree.

I'm not sure why you want this in the crt-list though, I think you meant
"show ssl cert"? The crt-list are only useful to manage multiple
certificates and SNIs on a bind line, in the case of a server line you
only need one certicate. 

-- 
William Lallemand



Re: [PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with SSL_CTRL_SET_MSG_CALLBACK macro

2021-02-08 Thread William Lallemand
On Mon, Feb 08, 2021 at 05:17:32PM +0500, Илья Шипицин wrote:
> usually I do such a stupid mistakes on friday.
> I wonder about next friday :(
> 
> new patch attached.
> 
> Ilya
> 

Don't worry it happens to me quite a lot :-)

Applied, thanks.

-- 
William Lallemand



Re: [PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with SSL_CTRL_SET_MSG_CALLBACK macro

2021-02-08 Thread William Lallemand
On Mon, Feb 08, 2021 at 05:03:43PM +0500, Илья Шипицин wrote:
> I've added commit message.
> 
> Ilya
> 

> From f39f9f69e29570fa43d7db5a0f08ee9395b98d50 Mon Sep 17 00:00:00 2001
> From: Ilya Shipitsin 
> Date: Sat, 23 Jan 2021 00:50:59 +0500
> Subject: [PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with
>  SSL_CTRL_SET_MSG_CALLBACK macro
> 
> ---
>  src/ssl_sock.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/ssl_sock.c b/src/ssl_sock.c
> index 24a38e47d..2bda3d765 100644
> --- a/src/ssl_sock.c
> +++ b/src/ssl_sock.c
> @@ -4224,7 +4224,7 @@ int ssl_sock_prepare_ctx(struct bind_conf *bind_conf, 
> struct ssl_bind_conf *ssl_
>  #endif /* OPENSSL_NO_DH */
>  
>   SSL_CTX_set_info_callback(ctx, ssl_sock_infocbk);
> -#if HA_OPENSSL_VERSION_NUMBER >= 0x00907000L
> +#ifdef SSL_CTRL_SET_MSG_CALLBACK
>   SSL_CTX_set_msg_callback(ctx, ssl_sock_msgcbk);
>  #endif
>  #ifdef HAVE_OPENSSL_KEYLOG
> -- 
> 2.29.2
> 

It looks like you sent the exact same patch by mistake.

-- 
William Lallemand



Re: [PATCH} improve ssl guarding

2021-02-07 Thread William Lallemand
On Sat, Feb 06, 2021 at 09:18:30PM +0500, Илья Шипицин wrote:
> you are right.
> I've fixed it.
>

Thanks, both pushed in master.

-- 
William Lallemand



Re: Makefile, environment variables and REGTESTS_TYPES

2021-02-05 Thread William Lallemand
On Fri, Feb 05, 2021 at 10:31:53AM +0100, William Lallemand wrote:

> Ok, I'm going to do the change in the help command then.
> 

In fact I just take a look again at this, and I think we've done the
patch the wrong way.

In 'run-regtests.sh' there is already a default setting:

REGTESTS_TYPES="${REGTESTS_TYPES:-any}"

So I suggest we change this one and remove the one from the Makefile, so we
could have the previous behavior.

The Makefile is not suppose to change these variables, even
HAPROXY_PROGRAM and VTEST_PROGRAM are not set in the Makefile.

It makes more sense this way in my opinion.

-- 
William Lallemand



Re: Makefile, environment variables and REGTESTS_TYPES

2021-02-05 Thread William Lallemand
On Fri, Feb 05, 2021 at 08:41:47AM +0100, Willy Tarreau wrote:
> Hi William,
> 
> On Fri, Jan 29, 2021 at 02:44:27PM +0100, William Lallemand wrote:
> > Hello List,
> > 
> > According to `make reg-tests-help` the REGTESTS_TYPES parameter must be
> > configured as an environment variable and not a make argument.
> > 
> > However since patch 3bad3d5 ("BUILD: Makefile: exclude broken tests by
> > default"), it does not work anymore with an environment variable. 
> > 
> > Looking at the several CI files we have, it is used as a make
> > argument everywhere.
> 
> I must confess I didn't even know it was expected to be used as an
> environment variable and have always used it as a make argument, given
> that these *are* exported as argument variables anyway.

I was surprised it was documented this way too, because we never used
the Makefile with environment variable before.

> Here's what I'm using for the make-reg-test-all script for example:
> 
>   make reg-tests VTEST_PROGRAM=/usr/local/bin/vtest 
> REGTESTS_TYPES=default,bug,devel,slow -- --j 8 "$@" || exit 1
> 
> > I'm going to update the `make reg-tests-help` command with the correct
> > syntax if there isn't any complain. 
> 
> OK.
> 
> > We could fix the issue by using "?=" when setting the default value, but
> > it would make it the only variable that use "?=" in the Makefile and I'm
> > not sure we want to proceed this way.
> 
> No please avoid this, I find the mixing of arguments and environment
> really confusing to use. The only valid use of "?=" is when you want
> to support pre-setting a variable that will be completed later,
> but this usually remains as it doesn't allow you to remove options,
> and in general it's really bad as you get different behaviors for
> 




>$ VAR=xxx make
> 
> and:
> 
>$ make VAR=xxx
> 
> I think the reg-test users are a small enough group that any required
> change can be quickly adopted if needed anyway, without having to take
> too much care about backwards compatibility, as long as it remains
> convenient to use.
> 

Ok, I'm going to do the change in the help command then.

-- 
William Lallemand



Makefile, environment variables and REGTESTS_TYPES

2021-01-29 Thread William Lallemand
Hello List,

According to `make reg-tests-help` the REGTESTS_TYPES parameter must be
configured as an environment variable and not a make argument.

However since patch 3bad3d5 ("BUILD: Makefile: exclude broken tests by
default"), it does not work anymore with an environment variable. 

Looking at the several CI files we have, it is used as a make
argument everywhere.

I'm going to update the `make reg-tests-help` command with the correct
syntax if there isn't any complain. 

We could fix the issue by using "?=" when setting the default value, but
it would make it the only variable that use "?=" in the Makefile and I'm
not sure we want to proceed this way.

Regards,

-- 
William Lallemand



Re: [PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with SSL_CTRL_SET_MSG_CALLBACK macro

2021-01-23 Thread William Lallemand
Hello,

On Sat, Jan 23, 2021 at 02:06:41AM +0500, Илья Шипицин wrote:
> Hello,
> 
> another ssl guard patch
> 
> Ilya

> From f39f9f69e29570fa43d7db5a0f08ee9395b98d50 Mon Sep 17 00:00:00 2001
> From: Ilya Shipitsin 
> Date: Sat, 23 Jan 2021 00:50:59 +0500
> Subject: [PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with
>  SSL_CTRL_SET_MSG_CALLBACK macro
> 
> ---
>  src/ssl_sock.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/ssl_sock.c b/src/ssl_sock.c
> index 24a38e47d..2bda3d765 100644
> --- a/src/ssl_sock.c
> +++ b/src/ssl_sock.c
> @@ -4224,7 +4224,7 @@ int ssl_sock_prepare_ctx(struct bind_conf *bind_conf, 
> struct ssl_bind_conf *ssl_
>  #endif /* OPENSSL_NO_DH */
>  
>   SSL_CTX_set_info_callback(ctx, ssl_sock_infocbk);
> -#if HA_OPENSSL_VERSION_NUMBER >= 0x00907000L
> +#ifdef SSL_CTRL_SET_MSG_CALLBACK
>   SSL_CTX_set_msg_callback(ctx, ssl_sock_msgcbk);
>  #endif
>  #ifdef HAVE_OPENSSL_KEYLOG
> -- 
> 2.29.2
> 

Please add a commit message in your patches, patches with only a subject
line won't be taken. See this part of the contributing rules:
https://github.com/haproxy/haproxy/blob/master/CONTRIBUTING#L455

Thanks,

-- 
William Lallemand



Re: [PATCH} improve ssl guarding

2021-01-23 Thread William Lallemand
On Sat, Jan 23, 2021 at 04:50:08PM +0500, Илья Шипицин wrote:
> Hello,
> 
> yet another guard improving patch (forgot to fix last time)
> 
> Ilya

Hello,

> From 5ce5623fac558d85c0ef0ec26dcffca754a87fae Mon Sep 17 00:00:00 2001
> From: Ilya Shipitsin 
> Date: Sat, 23 Jan 2021 16:38:33 +0500
> Subject: [PATCH 1/2] BUILD: ssl: guard SSL_CTX_add_server_custom_ext with
>  special macro
> 
> ---
>  src/ssl_sock.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/ssl_sock.c b/src/ssl_sock.c
> index 2bda3d765..803af393f 100644
> --- a/src/ssl_sock.c
> +++ b/src/ssl_sock.c
> @@ -6720,7 +6720,7 @@ static struct action_kw_list http_req_actions = {ILH, {
>  
>  INITCALL1(STG_REGISTER, http_req_keywords_register, _req_actions);
>  
> -#if (HA_OPENSSL_VERSION_NUMBER >= 0x1000200fL && !defined OPENSSL_NO_TLSEXT 
> && !defined OPENSSL_IS_BORINGSSL)
> +#ifdef HAVE_SL_CTX_ADD_SERVER_CUSTOM_EXT
>  

I believe you wanted to write "SSL_CTX" and not "SL_CTX" here?

>  static void ssl_sock_sctl_free_func(void *parent, void *ptr, CRYPTO_EX_DATA 
> *ad, int idx, long argl, void *argp)
>  {
> @@ -6818,7 +6818,7 @@ static void __ssl_sock_init(void)
>  #if defined(USE_THREAD) && (HA_OPENSSL_VERSION_NUMBER < 0x1010L)
>   ssl_locking_init();
>  #endif
> -#if (HA_OPENSSL_VERSION_NUMBER >= 0x1000200fL && !defined OPENSSL_NO_TLSEXT 
> && !defined OPENSSL_IS_BORINGSSL)
> +#ifdef HAVE_SL_CTX_ADD_SERVER_CUSTOM_EXT
>   sctl_ex_index = SSL_CTX_get_ex_new_index(0, NULL, NULL, NULL, 
> ssl_sock_sctl_free_func);
>  #endif
>  


-- 
William Lallemand



Re: [PATCH] improve ssl guarding by switching to macro SSL_CLIENT_HELLO_CB instead of openssl version

2021-01-22 Thread William Lallemand
On Sat, Jan 23, 2021 at 12:23:01AM +0500, Илья Шипицин wrote:
> updated patch attached
> 

Thanks, merged.

-- 
William Lallemand



Re: [PATCH] improve ssl guarding by switching to macro SSL_CLIENT_HELLO_CB instead of openssl version

2021-01-22 Thread William Lallemand
You could define a HAVE_SSL_* macro like it's done elsewhere in the
code, for example "HAVE_SSL_CLIENT_HELLO_CB".


On Fri, Jan 22, 2021 at 06:59:58PM +0500, Илья Шипицин wrote:
> ping
> 
> вт, 19 янв. 2021 г. в 23:24, Илья Шипицин :
> 
> > Any update on this?
> >
> > On Mon, Jan 18, 2021, 3:56 PM Илья Шипицин  wrote:
> >
> >> we can do nasty thing.
> >> SSL_CLIENT_HELLO_CB is not defined for BoringSSL, we can (in
> >> openssl-compat.h) check whether BoringSSL is used and define that macro.
> >>
> >> I'm not sure it is good thing.
> >>
> >> if you thing it is, please modify patch when applying. I'm ok with such
> >> change.
> >>
> >> пн, 18 янв. 2021 г. в 15:53, Илья Шипицин :
> >>
> >>>
> >>>
> >>> пн, 18 янв. 2021 г. в 15:09, William Lallemand :
> >>>
> >>>> Hello,
> >>>>
> >>>> On Sat, Jan 16, 2021 at 11:25:05PM +0500, Илья Шипицин wrote:
> >>>> > Hello,
> >>>> >
> >>>> > next openssl guarding patch
> >>>> >
> >>>> > Ilya
> >>>>
> >>>> > From b5ff0a9f1e0d2edc84981b39050e7f21d2b08ba8 Mon Sep 17 00:00:00 2001
> >>>> > From: Ilya Shipitsin 
> >>>> > Date: Sat, 16 Jan 2021 23:15:12 +0500
> >>>> > Subject: [PATCH] BUILD: ssl: guard Client Hello callbacks with
> >>>> >  SSL_CLIENT_HELLO_CB macro instead of openssl version
> >>>> >
> >>>> > ---
> >>>> >  include/haproxy/ssl_sock.h | 2 +-
> >>>> >  src/ssl_sock.c | 2 +-
> >>>> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >>>> >
> >>>> > diff --git a/include/haproxy/ssl_sock.h b/include/haproxy/ssl_sock.h
> >>>> > index ebfdb19ab..bde75b632 100644
> >>>> > --- a/include/haproxy/ssl_sock.h
> >>>> > +++ b/include/haproxy/ssl_sock.h
> >>>> > @@ -92,7 +92,7 @@ int ssl_sock_load_global_dh_param_from_file(const
> >>>> char *filename);
> >>>> >  void ssl_free_dh(void);
> >>>> >  #endif
> >>>> >  void ssl_free_engines(void);
> >>>> > -#if ((HA_OPENSSL_VERSION_NUMBER >= 0x10101000L) ||
> >>>> defined(OPENSSL_IS_BORINGSSL))
> >>>> > +#if (defined(SSL_CLIENT_HELLO_CB) || defined(OPENSSL_IS_BORINGSSL))
> >>>> >  int ssl_sock_switchctx_err_cbk(SSL *ssl, int *al, void *priv);
> >>>> >  #ifdef OPENSSL_IS_BORINGSSL
> >>>> >  int ssl_sock_switchctx_cbk(const struct ssl_early_callback_ctx *ctx);
> >>>> > diff --git a/src/ssl_sock.c b/src/ssl_sock.c
> >>>> > index 5ac81d36a..3e133d423 100644
> >>>> > --- a/src/ssl_sock.c
> >>>> > +++ b/src/ssl_sock.c
> >>>> > @@ -2290,7 +2290,7 @@ static void ssl_sock_switchctx_set(SSL *ssl,
> >>>> SSL_CTX *ctx)
> >>>> >   SSL_set_SSL_CTX(ssl, ctx);
> >>>> >  }
> >>>> >
> >>>> > -#if ((HA_OPENSSL_VERSION_NUMBER >= 0x10101000L) ||
> >>>> defined(OPENSSL_IS_BORINGSSL))
> >>>> > +#if (defined(SSL_CLIENT_HELLO_CB) || defined(OPENSSL_IS_BORINGSSL))
> >>>> >
> >>>> >  int ssl_sock_switchctx_err_cbk(SSL *ssl, int *al, void *priv)
> >>>> >  {
> >>>>
> >>>> We probably want to remove the defined(IS_BORINGSSL) from the
> >>>> ssl_sock.c too.
> >>>> Why don't you define a macro constant with the feature name in
> >>>> openssl-compat.h and test this constant in ssl_sock.c? Like it was done
> >>>> for various fonctions.
> >>>>
> >>>
> >>> it depends. I'd consider removing OPENSSL_IS_BORINGSSL as a future
> >>> improvements.
> >>>
> >>> this particular guard is used 2 times only (in *.h and *.c files),
> >>> readability is good.
> >>>
> >>>
> >>>
> >>>>
> >>>> Regards,
> >>>>
> >>>> --
> >>>> William Lallemand
> >>>>
> >>>

-- 
William Lallemand



Re: [PATCH 1/1] BUG/MINOR: worker: define _GNU_SOURCE for strsignal()

2021-01-21 Thread William Lallemand
On Thu, Jan 21, 2021 at 01:31:46AM +, Bertrand Jacquin wrote:
> glibc < 2.10 requires _GNU_SOURCE in order to make use of strsignal(),
> otherwise leading to SEGV at runtime.
> 
>   $ make V=1 TARGET=linux-glibc-legacy USE_THREAD= USE_ACCEPT4=
>   ..
>   src/mworker.c: In function 'mworker_catch_sigchld':
>   src/mworker.c:285: warning: implicit declaration of function 'strsignal'
>   src/mworker.c:285: warning: pointer/integer type mismatch in conditional 
> expression
>   ..
> 
>   $ make V=1 reg-tests REGTESTS_TYPES=slow,default
>   ..
>   ## Test case: reg-tests/mcli/mcli_start_progs.vtc ##
>   ## test results in: 
> "/tmp/haregtests-2021-01-19_15-18-07.n24989/vtc.29077.28f6153d"
>    h1Bad exit status: 0x008b exit 0x0 signal 11 core 128
>    h1Assert error in haproxy_wait(), src/vtc_haproxy.c line 792:  
> Condition(*(>fds[1]) >= 0) not true.  Errno=0 Success
>   ..
> 
>   $ gdb ./haproxy /tmp/core.0.haproxy.30270
>   ..
>   Core was generated by `/root/haproxy/haproxy -d -W -S fd@8 -dM -f 
> /tmp/haregtests-2021-01-19_15-18-07.'.
>   Program terminated with signal 11, Segmentation fault.
>   #0  0x2b387a10 in strlen () from /lib64/libc.so.6
>   (gdb) bt
>   #0  0x2b387a10 in strlen () from /lib64/libc.so.6
>   #1  0x2b354b69 in vfprintf () from /lib64/libc.so.6
>   #2  0x2b37788a in vsnprintf () from /lib64/libc.so.6
>   #3  0x004a76a3 in memvprintf (out=0x7fffedc680a0, format=0x5a5d58 
> "Current worker #%d (%d) exited with code %d (%s)\n", 
> orig_args=0x7fffedc680d0)
>   at src/tools.c:3868
>   #4  0x004bbd40 in print_message (label=0x58abed "ALERT", 
> fmt=0x5a5d58 "Current worker #%d (%d) exited with code %d (%s)\n", 
> argp=0x7fffedc680d0)
>   at src/log.c:1066
>   #5  0x004bc07f in ha_alert (fmt=0x5a5d58 "Current worker #%d (%d) 
> exited with code %d (%s)\n") at src/log.c:1109
>   #6  0x00534b7b in mworker_catch_sigchld (sh=) 
> at src/mworker.c:293
>   #7  0x00556af3 in __signal_process_queue () at src/signal.c:88
>   #8  0x004f6216 in signal_process_queue () at 
> include/haproxy/signal.h:39
>   #9  run_poll_loop () at src/haproxy.c:2859
>   #10 0x004f63b7 in run_thread_poll_loop (data=) 
> at src/haproxy.c:3028
>   #11 0x004faaac in main (argc=, 
> argv=0x7fffedc68498) at src/haproxy.c:904
> 
> See: https://man7.org/linux/man-pages/man3/strsignal.3.html

Thanks, merged. I've added the missing backport info in the commit message and 
renamed the worker tag by mworker.

-- 
William Lallemand



Re: [PATCH 1/3] MINOR: cache: Remove the `hash` part of the accept-encoding secondary key

2021-01-18 Thread William Lallemand


On Mon, Jan 18, 2021 at 01:40:44PM +0100, Tim Düsterhus wrote:
> Remi,
> 
> Am 18.01.21 um 11:24 schrieb Remi Tricot-Le Breton:
> > The patches look good to me. Just one point concerning the first one,
> > you could have removed everything related to ACCEPT_ENCODING_MAX_ENTRIES
> > since the limit was induced by the array that does not exist anymore.
> 
> I have intentionally opted to leave it as is, as a bit of a safety net.
> It is not going to make sense to send more than 16 *known* encodings at
> once. This limits processing time for an abusive client that sends:
> 
> accept-encoding: br,br,br,br,[…],br
> 
> > The comment of the accept_encoding_normalizer function does not match
> > its behavior anymore either.
> 
> Indeed. I adjusted that on v2.
> 
> Best regards
> Tim Düsterhus
> 

Thanks to both of you, applied.

-- 
William Lallemand



Re: [PATCH] BUG/MINOR: init: enforce strict-limits when using master-worker

2021-01-18 Thread William Lallemand
On Thu, Jan 14, 2021 at 12:13:17PM +0100, William Dauchy wrote:
> On Thu, Jan 14, 2021 at 11:21 AM William Lallemand
>  wrote:
> > VTest is not really suited to test the process management, for example
> > the tests doing a reload have timing issues because VTest is not able to
> > know when HAProxy is ready.
> >
> > Could you share what you tried to do? I'm not sure what is the problem
> > you are mentionning with -expectexit.
> 
> here it is:
> 
> varnishtest "strict-limits test"
> 
> #REQUIRE_VERSION=2.1
> 
> feature ignore_unknown_macro
> 
> server s1 {
> rxreq
> txresp
> } -repeat 2 -start
> 
> haproxy h1 -conf {
> global
> strict-limits
> maxconn 100
> 
> defaults
> mode http
> timeout connect 1s
> timeout client  1s
> timeout server  1s
> 
> frontend fe
> bind "fd@${fe}"
> default_backend be
> 
> backend be
> server s1 ${s1_addr}:${s1_port}
> } -start -expectexit 42
> 
> # give it some time to start and detect failure
> shell {
> sleep 1
> }
> 
> client c1 -connect ${h1_fe_sock} {
> txreq -url "/"
> } -run
> 
> - first, the sleep 1 really depends of the process init time, like you
> mentioned in your previous message, it is not possible to detect when
> process should be ready. So it remains very ugly.
> - the client triggers the `wait4` which is correctly ending with this error:
> *h1Expected exit: 0x2a signal: 0 core: 0
>  h1Bad exit status: 0x0100 exit 0x1 signal 0 core 0
> 
> - if I switch to no strict-limits, the process won't exit by itself;
> it does not trigger the `wait4` error, quite unclear why for now.

If I remember correctly the wait() is only done after a timeout of 10
seconds letting VTest run even if HAProxy exit immediatly. So I presume
HAProxy is still present as a zombie process during this time.
I don't know why it's done this way but this is a common problem I
have when starting VTest with an invalid haproxy configuration.

-- 
William Lallemand



Re: [PATCH] improve ssl guarding by switching to macro SSL_CLIENT_HELLO_CB instead of openssl version

2021-01-18 Thread William Lallemand
Hello,

On Sat, Jan 16, 2021 at 11:25:05PM +0500, Илья Шипицин wrote:
> Hello,
> 
> next openssl guarding patch
> 
> Ilya

> From b5ff0a9f1e0d2edc84981b39050e7f21d2b08ba8 Mon Sep 17 00:00:00 2001
> From: Ilya Shipitsin 
> Date: Sat, 16 Jan 2021 23:15:12 +0500
> Subject: [PATCH] BUILD: ssl: guard Client Hello callbacks with
>  SSL_CLIENT_HELLO_CB macro instead of openssl version
> 
> ---
>  include/haproxy/ssl_sock.h | 2 +-
>  src/ssl_sock.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/haproxy/ssl_sock.h b/include/haproxy/ssl_sock.h
> index ebfdb19ab..bde75b632 100644
> --- a/include/haproxy/ssl_sock.h
> +++ b/include/haproxy/ssl_sock.h
> @@ -92,7 +92,7 @@ int ssl_sock_load_global_dh_param_from_file(const char 
> *filename);
>  void ssl_free_dh(void);
>  #endif
>  void ssl_free_engines(void);
> -#if ((HA_OPENSSL_VERSION_NUMBER >= 0x10101000L) || 
> defined(OPENSSL_IS_BORINGSSL))
> +#if (defined(SSL_CLIENT_HELLO_CB) || defined(OPENSSL_IS_BORINGSSL))
>  int ssl_sock_switchctx_err_cbk(SSL *ssl, int *al, void *priv);
>  #ifdef OPENSSL_IS_BORINGSSL
>  int ssl_sock_switchctx_cbk(const struct ssl_early_callback_ctx *ctx);
> diff --git a/src/ssl_sock.c b/src/ssl_sock.c
> index 5ac81d36a..3e133d423 100644
> --- a/src/ssl_sock.c
> +++ b/src/ssl_sock.c
> @@ -2290,7 +2290,7 @@ static void ssl_sock_switchctx_set(SSL *ssl, SSL_CTX 
> *ctx)
>   SSL_set_SSL_CTX(ssl, ctx);
>  }
>  
> -#if ((HA_OPENSSL_VERSION_NUMBER >= 0x10101000L) || 
> defined(OPENSSL_IS_BORINGSSL))
> +#if (defined(SSL_CLIENT_HELLO_CB) || defined(OPENSSL_IS_BORINGSSL))
>  
>  int ssl_sock_switchctx_err_cbk(SSL *ssl, int *al, void *priv)
>  {

We probably want to remove the defined(IS_BORINGSSL) from the ssl_sock.c too.
Why don't you define a macro constant with the feature name in
openssl-compat.h and test this constant in ssl_sock.c? Like it was done
for various fonctions.

Regards,

-- 
William Lallemand



Re: [PATCH] MINOR: build: discard echoing in help target

2021-01-18 Thread William Lallemand
On Sun, Jan 17, 2021 at 06:47:47PM +, Bertrand Jacquin wrote:
> When V=1 is used in conjuction with help, the output becomes pretty
> difficult to read properly.
> 
>   $ make TARGET=linux-glibc V=1 help
>   ..
> DEBUG_USE_ABORT: use abort() for program termination, see 
> include/haproxy/bug.h for details
>   echo; \
>  if [ -n "" ]; then \
>if [ -n "" ]; then \
>   echo "Current TARGET: "; \
>else \
>   echo "Current TARGET:  (custom target)"; \
>fi; \
>  else \
>echo "TARGET not set, you may pass 'TARGET=xxx' to set one among :";\
>echo "  linux-glibc, linux-glibc-legacy, solaris, freebsd, dragonfly, 
> netbsd,"; \
>echo "  osx, openbsd, aix51, aix52, aix72-gcc, cygwin, haiku, 
> generic,"; \
>echo "  custom"; \
>  fi
> 
>   TARGET not set, you may pass 'TARGET=xxx' to set one among :
> linux-glibc, linux-glibc-legacy, solaris, freebsd, dragonfly, netbsd,
> osx, openbsd, aix51, aix52, aix72-gcc, cygwin, haiku, generic,
> custom
>   echo;echo "Enabled features for TARGET '' (disable with 'USE_xxx=') :"
> 
>   Enabled features for TARGET '' (disable with 'USE_xxx=') :
>   set --POLL  ; echo "  $*" | (fmt || 
> cat) 2>/dev/null
> POLL
>   echo;echo "Disabled features for TARGET '' (enable with 'USE_xxx=1') :"
> 
>   Disabled features for TARGET '' (enable with 'USE_xxx=1') :
>   set -- EPOLL KQUEUE NETFILTER PCRE PCRE_JIT PCRE2 PCRE2_JIT  PRIVATE_CACHE 
> THREAD PTHREAD_PSHARED BACKTRACE STATIC_PCRE STATIC_PCRE2 TPROXY LINUX_TPROXY 
> LINUX_SPLICE LIBCRYPT CRYPT_H GETADDRINFO OPENSSL LUA FUTEX ACCEPT4 CLOSEFROM 
> ZLIB SLZ CPU_AFFINITY TFO NS DL RT DEVICEATLAS 51DEGREES WURFL SYSTEMD 
> OBSOLETE_LINKER PRCTL THREAD_DUMP EVPORTS OT QUIC; echo "  $*" | (fmt || cat) 
> 2>/dev/null
> EPOLL KQUEUE NETFILTER PCRE PCRE_JIT PCRE2 PCRE2_JIT PRIVATE_CACHE
> 
> This commit ensure the help target always discard line echoing
> regardless of V variable as done for reg-tests-help target.

Thanks, merged!

-- 
William Lallemand



Re: [PATCH] DOC: replace use of HAproxy with HAProxy

2021-01-17 Thread William Lallemand
On Sun, Jan 17, 2021 at 07:18:44PM +, Bertrand Jacquin wrote:
> This is a pretty lame commit in a attempt to use a common wording of
> HAProxy used 1319 times compared to HAproxy used 18 times
> ---
> index 1b6c21d10bb7..ad94211d4b31 100644
> --- a/doc/regression-testing.txt
> +++ b/doc/regression-testing.txt
> @@ -179,7 +179,7 @@ status. Here is the output when running this VTC file:
>   h10.0 macro def h1_pid=6395
>   h10.0 macro def h1_name=/tmp/vtc.6377.64329194/h1
>  **   h10.0 Wait
> -**   h10.0 Stop HAproxy pid=6395
> +**   h10.0 Stop HAProxy pid=6395
>   h10.0 STDOUT poll 0x10
>  **   h10.0 WAIT4 pid=6395 status=0x008b (user 0.00 sys 0.00)
>  *h10.0 Expected exit: 0x1 signal: 0 core: 0
> @@ -227,7 +227,7 @@ as expected (verbose mode execution):
>   h10.0 macro def h1_pid=25558
>   h10.0 macro def h1_name=/tmp/vtc.25540.59b6ec5d/h1
>  **   h10.0 Wait
> -**   h10.0 Stop HAproxy pid=25558
> +**   h10.0 Stop HAProxy pid=25558
>  ***  h10.0 debug|[ALERT] 157/135318 (25558) : parsing 
> [/tmp/vtc.25540.59b6ec5d/h1/cfg:10] : 'filter' : ''spoe' : missing config 
> file'
>  ***  h10.0 debug|[ALERT] 157/135318 (25558) : Error(s) found in 
> configuration file : /tmp/vtc.25540.59b6ec5d/h1/cfg
>  ***  h10.0 debug|[ALERT] 157/135318 (25558) : Fatal errors found in 
> configuration.
> @@ -318,7 +318,7 @@ client and 's1' server with 'http1' as haproxy frontend. 
> This frontend listen
>  on TCP socket with 'my_frontend_fd' as file descriptor.
>  
>  # Mandatory line
> -varnishtest "Basic HAproxy test"
> +varnishtest "Basic HAProxy test"
>  
>  # As some macros for haproxy are used in this file, this line is 
> mandatory.
>  feature ignore_unknown_macro
> @@ -558,7 +558,7 @@ Here is the output produced by varnishtest with the 
> latter VTC file:
>  *top   0.0 RESETTING after 
> /home/fred/src/varnish-cache-haproxy/d02286d.vtc
>  **   h10.0 Reset and free h1 haproxy 15787
>  **   h10.0 Wait
> -**   h10.0 Stop HAproxy pid=15787
> +**   h10.0 Stop HAProxy pid=15787
>   h10.0 Kill(2)=0: Success
>   h10.0 STDOUT poll 0x10
>  **   h10.1 WAIT4 pid=15787 status=0x0002 (user 0.00 sys 0.004000)
> @@ -693,7 +693,7 @@ of the "syslog" "expect" command:
>  *top   0.0 RESETTING after 
> /home/fred/src/varnish-cache-haproxy/d02286d.vtc
>  **   h10.0 Reset and free h1 haproxy 12728
>  **   h10.0 Wait
> -**   h10.0 Stop HAproxy pid=12728
> +**   h10.0 Stop HAProxy pid=12728
>   h10.0 Kill(2)=0: Success
>  **** h1    0.0 STDOUT poll 0x10
>  **   h10.1 WAIT4 pid=12728 status=0x0002 (user 0.00 sys 0.004000)

These are VTest output, you probably want to patch VTest or the example
won't be accurate!

-- 
William Lallemand



Re: [PATCH] DOC: replace use of HA-Proxy with HAProxy

2021-01-17 Thread William Lallemand
Hello Bertrand,

On Sun, Jan 17, 2021 at 06:58:46PM +, Bertrand Jacquin wrote:
> This is a pretty lame commit in a attempt to use a common wording of
> HAProxy used 1319 times compared to HAproxy used 10 times
> index e36e020c5ce7..92449a04f6e2 100644
> 
> [...]
>
> --- a/src/haproxy.c
> +++ b/src/haproxy.c
> @@ -537,7 +537,7 @@ static void display_version()
>  {
>   struct utsname utsname;
>  
> - printf("HA-Proxy version %s %s - https://haproxy.org/\n;
> + printf("HAProxy version %s %s - https://haproxy.org/\n;
>  PRODUCT_STATUS "\n", haproxy_version, haproxy_date);
>  
>   if (strlen(PRODUCT_URL_BUGS) > 0) {
> 

I wanted to do this a long time ago, and at this time we decided to keep
it as it was to not break existing scripts. I think we'll let Willy
decide if that's a good idea now :-)

Regards,

-- 
William Lallemand



Re: [PATCH] BUG/MINOR: init: enforce strict-limits when using master-worker

2021-01-14 Thread William Lallemand
On Thu, Jan 14, 2021 at 10:35:27AM +0100, William Dauchy wrote:
> On Wed, Jan 13, 2021 at 1:22 PM William Lallemand
>  wrote:
> > Thanks to both of you! merged in master.
> 
> a side note: yesterday evening I wanted to have a look at a reg-test
> in order to prevent it in the future, but it looks like `-expectexit`
> from haproxy varnishtest is not really designed for that. I manage to
> detect it if I put another command after haproxy which triggers the
> `wait4` at some point but it is really ugly.
> So I believe this would require a patch on varnishtest side first if
> we want to have a reg-tests on this.

VTest is not really suited to test the process management, for example
the tests doing a reload have timing issues because VTest is not able to
know when HAProxy is ready.

Could you share what you tried to do? I'm not sure what is the problem
you are mentionning with -expectexit.

Thanks

-- 
William Lallemand



Re: [PATCH] BUG/MINOR: init: enforce strict-limits when using master-worker

2021-01-13 Thread William Lallemand
On Wed, Jan 13, 2021 at 11:46:52AM +0100, Jerome Magnin wrote:
> On Wed, Jan 13, 2021 at 11:34:07AM +0100, William Dauchy wrote:
> > On Wed, Jan 13, 2021 at 11:06 AM William Dauchy  wrote:
> > I spend some time on it, trying to find a good explanation but it
> > seems like I truly screw up. I probably overlooked the master worker
> > test. So at the end forget my comment on the commit message, it seems
> > like it never worked in master worker mode.
> > 
> > Sorry for that!
> 
> no worries, I've updated the commit message to mention your review.
> thanks for your time reviewing the issue.
> regards,

Thanks to both of you! merged in master.

-- 
William Lallemand



Re: [ANNOUNCE] haproxy-2.4-dev5

2021-01-07 Thread William Lallemand
On Thu, Jan 07, 2021 at 11:21:07AM +0100, Willy Tarreau wrote:
> On Thu, Jan 07, 2021 at 11:03:14AM +0100, William Dauchy wrote:
> > On Wed, Jan 6, 2021 at 5:45 PM Willy Tarreau  wrote:
> > > HAProxy 2.4-dev5 was released on 2021/01/06. It added 91 new commits
> > > after version 2.4-dev4.
> > 
> > unclear whether this is on my side only because I did not investigate
> > but I have two tests failing for a while now:
> > 
> > ## Starting vtest ##
> > Testing with haproxy version: 2.4-dev5-761d64-4
> > #top  TEST reg-tests/filters/random-forwarding.vtc FAILED (0.192) exit=2
> > #top  TEST reg-tests/seamless-reload/abns_socket.vtc FAILED (2.215) 
> > exit=2
> 
> I didn't observe them, they all succeed on my side, and just checking
> the CI, it seems they succeed. But that doesn't mean they're reliable
> or anything, very often regtests start to fail sporadically in a single
> environment before we figure the problem.
> 

These reg-tests are of types "slow" and "broken" not launched by the CI.
 

-- 
William Lallemand



Re: [PATCH] improve SSL guarding, use macro instead of openssl version

2021-01-07 Thread William Lallemand
On Thu, Jan 07, 2021 at 12:28:02PM +0500, Илья Шипицин wrote:
> Hi,
> 
> another series of removing HA_OPENSSL_VERSION
> 
> Ilya


Thanks, merged.



-- 
William Lallemand



Re: [PATCH 1/2] CLEANUP: Reduce scope of `header_name` in http_action_store_cache()

2021-01-05 Thread William Lallemand
On Sat, Jan 02, 2021 at 10:47:16PM +0100, Tim Duesterhus wrote:
> This variable is only needed deeply nested in a single location and clang's
> static analyzer complains about a dead initialization. Reduce the scope to
> satisfy clang and the human that reads the function.


On Sat, Jan 02, 2021 at 10:47:17PM +0100, Tim Duesterhus wrote:
> This is only required to process the `age` header.


Thanks Tim, pushed in master.

-- 
William Lallemand



Re: [PATCH] more granular guard for SSL_CTX_add_server_custom_ext

2020-12-15 Thread William Lallemand
On Fri, Dec 11, 2020 at 09:58:31PM +0500, Илья Шипицин wrote:
> ping :)
> 
> пт, 27 нояб. 2020 г. в 02:58, Илья Шипицин :
> 
> > Hello,
> >
> > let us continue to improve ssl guarding.
> >
> > Ilya
> >

Thanks, merged.

-- 
William Lallemand



Re: HAproxy 2.2.5 possible bug in ssl crt-list socket commands?

2020-12-15 Thread William Lallemand
On Fri, Dec 11, 2020 at 10:19:22AM +, Froehlich, Dominik wrote:
> Hi,
> 
> I am trying to implement a dynamic certificate updater for my crt-list in 
> HAproxy 2.2.5.
> I have noticed that somehow, when I update an existing certificate and add it 
> to the crt-list twice, I can never remove it again.
> 

For people interested, the bug was discussed here:
https://github.com/haproxy/haproxy/issues/1004

-- 
William Lallemand



Re: dynamic ssl certificate updates with changed intermediate

2020-12-11 Thread William Lallemand
On Fri, Dec 11, 2020 at 02:53:13PM +0100, Björn Jacke wrote:
> Hi William,
> 
> On 11.12.20 12:29, William Lallemand wrote:
> > If we want the "set ssl ocsp-response" command to work in this particular 
> > case,
> > I think we need to change the key, but the problem is that the OCSP response
> > only contains an OCSP_CERTID for helping us finding where we should apply 
> > the
> > certificate, and the serialNumber alone is not enough to index the response.
> 
> thanks to your description I understand the technical background but I
> think it's a usability issue for people running haproxy. If people
> follow setting up hitless certificate updates as described at
> https://www.haproxy.com/blog/dynamic-ssl-certificate-storage-in-haproxy/
> then it will not be clear how to set this up correct if you use ocsp
> stapling also. Finding the underlying problem is not quite easy. Most
> people who run haproxy with dynamic updates and ocsp stapling enabled,
> will probably run into the same problem. Now that the letsencrypt is
> about to issue certs with a different intermediate cert (and soon will
> change again the intermediate for ecdsa certs), this problem might pop
> up for more people.
> 

In my opinion the problem is that there is no warning during the "set ssl
cert" and that it allowed you to commit silently. In this particular
case we should have a warning which states that the ocsp response must
be updated before the commit.

-- 
William Lallemand



Re: dynamic ssl certificate updates with changed intermediate

2020-12-11 Thread William Lallemand
Hello Björn,

On Thu, Dec 10, 2020 at 08:14:35PM +0100, Björn Jacke wrote:
>
> What I'm finally wondering: The need for running a "set ssl cert
> fullchain.pem.ocsp" is not intended but instead the matching ocsp
> response *should* be loaded again automatically, if a certificate (with
> or without intermediate cert changes) was replaced right? If you want I
> can file an issue to track this.

The OCSP is activated by storing the configured response in a tree
during the loading of the configuration (or the set ssl cert).
This response is indexed with a key which is a OCSP_CERTID structure,
which contains the issuer name hash and the issuer key hash.

/*-  CertID ::= SEQUENCE {
 *   hashAlgorithmAlgorithmIdentifier,
 *   issuerNameHash OCTET STRING, -- Hash of Issuer's DN
 *   issuerKeyHash  OCTET STRING, -- Hash of Issuers public key 
(excluding the tag & length fields)
 *   serialNumber   CertificateSerialNumber }
 */
struct ocsp_cert_id_st {
X509_ALGOR hashAlgorithm;
ASN1_OCTET_STRING issuerNameHash;
ASN1_OCTET_STRING issuerKeyHash;
ASN1_INTEGER serialNumber;
};

A pointer to this node is then stored in the SSL context so it can be
used by the OCSP callback.

During an update with the "set ssl ocsp-response", an OCSP_CERTID is
extracted from the new response, and a lookup is done in the tree to
replace the previous one. If we didn't find the corresponding
OCSP_CERTID in the tree the message "OCSP single response: Certificate
ID does not match any certificate or issuer" is issued. This is the
problem you have because the issuer hashes changed.

If we want the "set ssl ocsp-response" command to work in this particular case,
I think we need to change the key, but the problem is that the OCSP response
only contains an OCSP_CERTID for helping us finding where we should apply the
certificate, and the serialNumber alone is not enough to index the response.

-- 
William Lallemand



Re: dynamic ssl certificate updates with changed intermediate

2020-12-10 Thread William Lallemand
On Thu, Dec 10, 2020 at 03:24:39PM +0100, Björn Jacke wrote:
> Hi William,
> 
> On 09.12.20 09:27, William Lallemand wrote:
> > $ echo -e -n "@1 set ssl cert server1.fullchain.pem <<\n$(cat 
> > server2.fullchain.pem)\n\n" | socat - /tmp/master.socket
> > $ echo -e "@1 set ssl cert server1.fullchain.pem.ocsp <<\n$(base64 -w 
> > 1 server2.fullchain.ocsp)\n" | socat - /tmp/master.socket
> > $ echo "@1 commit ssl cert server1.fullchain.pem" | socat - 
> > /tmp/master.socket
> > 
> > It should activate the OCSP with the new SSL context.
> 
> thanks, yes, using "set ssl cert fullchain.pem.ocsp" instead of "set ssl
> ocsp-response ..." makes it succeed.
> 
> As far as I can see the "set ssl cert fullchain.pem.ocsp" method is
> *generally* suitable to update ocsp responses and can be used as a drop
> in replacement for the "set ssl ocsp-response" method, which is not
> working correctly in the case, where the intermediate cert changed?
> 

The "set ssl cert" method generates the new SSL context the same way it
is done with a reload. So it's a little bit heavier than just updating
the OCSP response.

If you commit the certificate without the .ocsp, it's like you
reloaded haproxy with the previous .ocsp file.

-- 
William Lallemand



Re: dynamic ssl certificate updates with changed intermediate

2020-12-09 Thread William Lallemand
On Tue, Dec 08, 2020 at 06:42:13PM +0100, Björn Jacke wrote:
> Hi William,
> 
>  On 08.12.20 15:13, William Lallemand wrote:> I then updated the
> certificate this way:
> > 
> > $ echo -e -n "@1 set ssl cert server1.fullchain.pem <<\n$(cat 
> > server2.fullchain.pem)\n\n" | socat - /tmp/master.socket 
> > Transaction created for certificate server1.fullchain.pem!
> > 
> > $ echo "@1 commit ssl cert server1.fullchain.pem" | socat - 
> > /tmp/master.socket 
> > Committing server1.fullchain.pem.
> > Success!
> > 
> > And checked that the certificate is correctly updated:
> 
> true, what fail though is the dynamic ocsp-response update after that,
> sorry for the unprecise problem description before. This happens after a
> dynamic cert update that *includes* an intermediate cert update if you
> then also try make a dynamic ocsp-response update:
> 
> # echo "set ssl ocsp-response $(base64 -w 1 ${DIRNAME}/ocsp.der)" |
> socat ...
> 
> OCSP single response: Certificate ID does not match any certificate or
> issuer.
> 

Hello,

Okay thanks for confirming.

Could you try this method?

$ echo -e -n "@1 set ssl cert server1.fullchain.pem <<\n$(cat 
server2.fullchain.pem)\n\n" | socat - /tmp/master.socket
$ echo -e "@1 set ssl cert server1.fullchain.pem.ocsp <<\n$(base64 -w 
1 server2.fullchain.ocsp)\n" | socat - /tmp/master.socket
$ echo "@1 commit ssl cert server1.fullchain.pem" | socat - 
/tmp/master.socket

It should activate the OCSP with the new SSL context.

-- 
William Lallemand



Re: dynamic ssl certificate updates with changed intermediate

2020-12-08 Thread William Lallemand
On Tue, Dec 08, 2020 at 11:48:41AM +0100, William Lallemand wrote:
> On Sat, Dec 05, 2020 at 02:57:03AM +0100, Björn Jacke wrote:
> > Hi,
> > 
> > I ran into an issue with haproxy 2.2.6, where I'm not sure if this is
> > working as intended or not. I have a frontend, which has a ssl cert
> > configured in a combined pam file, containing the private, public and
> > intermediate certificate. The bind line looks like this:
> > 
> > bind 203.0.113.1 ssl crt /certs/host.example.org/combined.pem.rsa ...
> > 
> > If I renew the certificate, it works as also shown in
> > 
> > https://www.haproxy.com/blog/dynamic-ssl-certificate-storage-in-haproxy/
> > 
> > via
> > 
> > echo "set ssl cert ${DIRNAME}/combined.pem.rsa" | socat ...
> > 
> > Everything worked fine since quite a while ...
> > 
> > until now the issuing intermediate certificate changed. I would expect
> > that above mentioned "set ssl cert combined.pem.rsa" would also update
> > the intermediate certificate - but the *previous* intermediate is still
> > being used by haproxy. I noticed this actually only because the "set ssl
> > ocsp-response" returned "Certificate ID does not match any certificate
> > or issuer". It took me quite a while to spot that the intermediate was
> > not updated.
> > 
> > So the final question is, is this a bug or is the intermediate not
> > supposed to be updated along with the combined.pem but differently? A
> > reload or restart of haproxy will activate the new intermediate
> > certificate of course.
> > 
> 
> Looks like a bug to me, the intermediate certificate is indeed supposed
> to be updated, I'll look into this.
> 

I made some tests and I can't reproduce the issue, could you check with
the CLI that the intermediate changed with "show ssl cert"

This is the test I made:

1 Root CA, 2 Intermediates, 2 server certificates made with each intermediates.

cat server1.key server1.crt intermediateCA1.crt > server1.fullchain.pem
cat server1.key server1.crt intermediateCA1.crt > server2.fullchain.pem

$ echo "@1 show ssl cert server1.fullchain.pem" | socat - 
/tmp/master.socket 
Filename: server1.fullchain.pem
Status: Used
Serial: 19018ED789D84428F15631EEDD946E254D3F
notBefore: Dec  8 13:30:47 2020 GMT
notAfter: Sep  4 13:30:47 2023 GMT
Subject Alternative Name: 
Algorithm: RSA2048
SHA1 FingerPrint: 74BB48E0F47B89AEE68A8173774B446775CDA0A3
Subject: /C=AU/ST=Some-State/O=Foobar Server1/CN=server1.foobar.local
Issuer: /C=AU/ST=Some-State/O=Foobar Int/CN=int1.foobar.local
Chain Subject: /C=AU/ST=Some-State/O=Foobar Int/CN=int1.foobar.local
Chain Issuer: /C=AU/ST=Some-State/O=Foobar ROOT/CN=root.foobar.local


I then updated the certificate this way:

$ echo -e -n "@1 set ssl cert server1.fullchain.pem <<\n$(cat 
server2.fullchain.pem)\n\n" | socat - /tmp/master.socket 
Transaction created for certificate server1.fullchain.pem!

$ echo "@1 commit ssl cert server1.fullchain.pem" | socat - 
/tmp/master.socket 
Committing server1.fullchain.pem.
Success!

And checked that the certificate is correctly updated:


$ echo "@1 show ssl cert server1.fullchain.pem" | socat - 
/tmp/master.socket 
Filename: server1.fullchain.pem
Status: Used
Serial: 0808AAE72CD605D64FE5FEACA9FC8B3BA33F69E2
notBefore: Dec  8 13:33:26 2020 GMT
notAfter: Sep  4 13:33:26 2023 GMT
Subject Alternative Name: 
Algorithm: RSA2048
SHA1 FingerPrint: E60B288CE48BDAEE9A234DCE16DF0A05E4C4E1BE
Subject: /C=AU/ST=Some-State/O=Foobar Server2/CN=server2.foobar.local
Issuer: /C=AU/ST=Some-State/O=Foobar Int2/CN=int2.foobar.local
Chain Subject: /C=AU/ST=Some-State/O=Foobar Int2/CN=int2.foobar.local
Chain Issuer: /C=AU/ST=Some-State/O=Foobar ROOT/CN=root.foobar.local

You can see at the end of the output that the certificate and the chain was 
updated.
You can also check the chain returned by haproxy with `openssl s_client
-showcerts -connect localhost:8443 -servername server2.foobar.local`


Regards,

-- 
William Lallemand



Re: dynamic ssl certificate updates with changed intermediate

2020-12-08 Thread William Lallemand
On Sat, Dec 05, 2020 at 02:57:03AM +0100, Björn Jacke wrote:
> Hi,
> 
> I ran into an issue with haproxy 2.2.6, where I'm not sure if this is
> working as intended or not. I have a frontend, which has a ssl cert
> configured in a combined pam file, containing the private, public and
> intermediate certificate. The bind line looks like this:
> 
> bind 203.0.113.1 ssl crt /certs/host.example.org/combined.pem.rsa ...
> 
> If I renew the certificate, it works as also shown in
> 
> https://www.haproxy.com/blog/dynamic-ssl-certificate-storage-in-haproxy/
> 
> via
> 
> echo "set ssl cert ${DIRNAME}/combined.pem.rsa" | socat ...
> 
> Everything worked fine since quite a while ...
> 
> until now the issuing intermediate certificate changed. I would expect
> that above mentioned "set ssl cert combined.pem.rsa" would also update
> the intermediate certificate - but the *previous* intermediate is still
> being used by haproxy. I noticed this actually only because the "set ssl
> ocsp-response" returned "Certificate ID does not match any certificate
> or issuer". It took me quite a while to spot that the intermediate was
> not updated.
> 
> So the final question is, is this a bug or is the intermediate not
> supposed to be updated along with the combined.pem but differently? A
> reload or restart of haproxy will activate the new intermediate
> certificate of course.
> 

Looks like a bug to me, the intermediate certificate is indeed supposed
to be updated, I'll look into this.

-- 
William Lallemand



[ANNOUNCE] haproxy-2.3.2

2020-11-28 Thread William Lallemand
Hi,

HAProxy 2.3.2 was released on 2020/11/28. It added 34 new commits
after version 2.3.1.

This version fixes some bugs:

Willy fixed a bug in the peers protocol which was introduced in the previous
2.3.1 version when trying to fix a bug. This bug could lead to a process
killed by the watchdog.

Christopher fixed a possible overflow in the offset variable when using
using the filters.

He also fixed a mess with the checks buffers that could lead to a segmentation
fault when a h2 health-check is performed.

Less important but still interesting patches:

I fixed a problem with the SSL certificates loading which was ignoring
non-existing files and let haproxy starts without any error in this case.

The cache behavior was changed a little bit to respect a little more the
standard, indeed Rémi made a patch which forbids caching of response which
does not contains a explicit expiration time. Since we are still early in the
2.3 life, we decided to backport it.

We also backported the "del-header -m " feature developed by Marciej
which allows to use various match method (including regexes) to delete a
header.

The other fixes and patches are listed in the complete changelog below.

As usual it is recommanded to update to this version if you use a previous 2.3
release.

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
   Wiki : https://github.com/haproxy/wiki/wiki
   Sources  : http://www.haproxy.org/download/2.3/src/
   Git repository   : http://git.haproxy.org/git/haproxy-2.3.git/
   Git Web browsing : http://git.haproxy.org/?p=haproxy-2.3.git
   Changelog: http://www.haproxy.org/download/2.3/src/CHANGELOG
   Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/


---
Complete changelog :
Christopher Faulet (9):
  BUG/MEDIUM: filters: Forward all filtered data at the end of http 
filtering
  BUG/MINOR: http-ana: Don't wait for the body of CONNECT requests
  BUG/MEDIUM: http-ana: Don't eval http-after-response ruleset on empty 
messages
  BUG/MAJOR: filters: Always keep all offsets up to date during data 
filtering
  BUG/MINOR: tcpcheck: Don't forget to reset tcp-check flags on new kind of 
check
  MINOR: tcpcheck: Don't handle anymore in-progress send rules in 
tcpcheck_main
  BUG/MAJOR: tcpcheck: Allocate input and output buffers from the buffer 
pool
  DOC: config: Move req.hdrs and req.hdrs_bin in L7 samples fetches section
  BUG/MINOR: http-fetch: Fix smp_fetch_body() when called from a 
health-check

Jerome Magnin (1):
  CLEANUP: cfgparse: remove duplicate registration for transparent build 
options

Joao Morais (2):
  DOC: clarify how to create a fallback crt
  DOC: better describes how to configure a fallback crt

Maciej Zdeb (4):
  BUG/MINOR: http_htx: Fix searching headers by substring
  MINOR: http_act: Add -m flag for del-header name matching method
  BUG/MEDIUM: http_act: Restore init of log-format list
  DOC: Clarify %HP description in log-format

Matthieu Guegan (1):
  BUILD: makefile: enable crypt(3) for OpenBSD

Remi Tricot-Le Breton (2):
  MEDIUM: cache: Change caching conditions
  DOC: cache: Add new caching limitation information

Tim Duesterhus (3):
  REGTESTS: Add sample_fetches/cook.vtc
  BUILD: Make DEBUG part of .build_opts
  BUILD: Show the value of DEBUG= in haproxy -vv

William Dauchy (1):
  REGTESTS: converter: add url_dec test

William Lallemand (6):
  DOC: add missing 3.10 in the summary
  BUG/MINOR: ssl: segv on startup when AKID but no keyid
  BUG/MEDIUM: ssl/crt-list: bundle support broken in crt-list
  BUG/MEDIUM: ssl: error when no certificate are found
  BUG/MINOR: ssl/crt-list: load bundle in crt-list only if activated
  BUG/MEDIUM: ssl/crt-list: fix error when no file found

Willy Tarreau (5):
  BUILD: http-htx: fix build warning regarding long type in printf
  CLEANUP: connection: do not use conn->owner when the session is known
  BUG/MAJOR: connection: reset conn->owner when detaching from session list
  BUG/MAJOR: peers: fix partial message decoding
  DOC: better document the config file format and escaping/quoting rules

---

-- 
William Lallemand



Re: openssl-3.0 ?

2020-11-27 Thread William Lallemand
On Fri, Nov 27, 2020 at 11:08:54AM +0500, Илья Шипицин wrote:
> hi,
> 
> stable openssl 3.0 is going to be released soon.
> 
> lots of things deprecated, have a look:
> 
> https://github.com/chipitsine/haproxy/runs/1461112182
> 

As far as I know, some of the API were not totally replaced (the ENGINE
part for example) so we can't remove that for now. The deprecated flag
is an indicator and I don't know any distribution which build with this
way, so we are safe for now, but we should definitively migrate what is
deprecated if that's possible.

-- 
William Lallemand



Re: [PATCH] DOC: clarify how to create a fallback crt

2020-11-24 Thread William Lallemand
On Tue, Nov 24, 2020 at 08:59:05AM -0300, Joao Morais wrote:
> 
> 
> > Em 24 de nov de 2020, à(s) 05:47, William Lallemand 
> >  escreveu:
> > 
> > Hello Joao,
> > 
> > On Sat, Nov 21, 2020 at 12:33:38PM -0300, Joao Morais wrote:
> >> 
> >> It’s indeed rather confusing, sorry about the mess.
> >> 
> >> Here is a new proposal of the last paragraph, how it sounds? - suggestions 
> >> welcome, note that I’m not very familiar with english
> >> 
> >> 
> >> 
> >>  The first declared certificate of a bind line is used as the default
> >>  certificate, either from crt or crt-list option, which haproxy should use 
> >> in
> >>  the TLS handshake if no other certificate matches. This certificate will 
> >> also
> >>  be used if the provided SNI matches its CN or SAN, even if a matching SNI
> >>  filter is found on any crt-list. The SNI filter !* can be used after the 
> >> first
> >>  declared certificate to not include its CN and SAN in the SNI tree, so it 
> >> will
> >>  never match except if no other certificate matches. This way the first
> >>  declared certificate act as a fallback.
> > 
> > It looks good in my opinion, can you make a new patch for it?
> 
> Sure! Attached a new patch on top of current master.
> 


Merged, thanks!


-- 
William Lallemand



Re: [PATCH] unveal the power of BoringSSL by setting its own version back to 1.1.1

2020-11-24 Thread William Lallemand
On Sat, Nov 21, 2020 at 11:23:32PM +0500, Илья Шипицин wrote:
> hopefully final BoringSSL patches this week.
> 
> Ilya


Thanks, all merged!

-- 
William Lallemand



Re: [PATCH] DOC: clarify how to create a fallback crt

2020-11-24 Thread William Lallemand
Hello Joao,

On Sat, Nov 21, 2020 at 12:33:38PM -0300, Joao Morais wrote:
> 
> It’s indeed rather confusing, sorry about the mess.
> 
> Here is a new proposal of the last paragraph, how it sounds? - suggestions 
> welcome, note that I’m not very familiar with english
> 
> 
> 
>   The first declared certificate of a bind line is used as the default
>   certificate, either from crt or crt-list option, which haproxy should use in
>   the TLS handshake if no other certificate matches. This certificate will 
> also
>   be used if the provided SNI matches its CN or SAN, even if a matching SNI
>   filter is found on any crt-list. The SNI filter !* can be used after the 
> first
>   declared certificate to not include its CN and SAN in the SNI tree, so it 
> will
>   never match except if no other certificate matches. This way the first
>   declared certificate act as a fallback.

It looks good in my opinion, can you make a new patch for it?

Thanks

-- 
William Lallemand



Re: [PATCH] DOC: clarify how to create a fallback crt

2020-11-21 Thread William Lallemand
On Sat, Nov 21, 2020 at 07:48:48AM -0300, Joao Morais wrote:
> 
> The attached patch adds some clarification on how one can declare a
> proper fallback certificate using crt-list. Feel free to ask me to
> tune verbosity to a higher or lower level.
> 

That's actually a bit confusing, because the first line of a crt-list is
not the default certificate. The default certificate is the first
certificate declared on a bind line.

For example:

bind :443 ssl crt default.pem crt-list list1.crtlist
bind :443 ssl crt-list list1.crtlist crt-list list2.crtlist

In the first case, the fallback certificate will be "default.pem", and
in the second case, it will be the fist line of "list1.crtlist".


-- 
William Lallemand



Re: [PATCH] DOC: clarify how to create a fallback crt

2020-11-21 Thread William Lallemand
On Sat, Nov 21, 2020 at 07:48:48AM -0300, Joao Morais wrote:

-- 
William Lallemand


0001-DOC-clarify-how-to-create-a-fallback-crt.patch
Description: Binary data


Re: [PATCH] simplify openssl async detection

2020-11-19 Thread William Lallemand
On Thu, Nov 19, 2020 at 12:58:06AM +0500, Илья Шипицин wrote:
> ping :) ?
> 
> сб, 14 нояб. 2020 г. в 02:04, Илья Шипицин :
> 
> > Hi.
> >
> > next define improvement.
> >
> > Ilya
> >

Thanks, merged.

-- 
William Lallemand



Re: [PATCH v5 0/2] add set server ssl command

2020-11-18 Thread William Lallemand
On Sat, Nov 14, 2020 at 07:25:31PM +0100, William Dauchy wrote:
> Hello,
> 
> This patchset is an attempt to add a new command for configure ssl on
> server at runtime:
> 
> - the first patch is a simple preparation work
> - the second one is adding the new command. Now that I understand how
>   ssl backend connections are initialized, I change it to: init SSL
>   connection at startup. The command is only here to de/activate the SSL
>   connection.
> 
> remaining point for another patchset:
> - to follow up the work done on `show stats` with weight done by Willy,
>   I am thinking to display use_ssl in that command as well, completely
>   removing the use of `show servers state` for our own use case. As
>   stated by Willy, we however need to make sure not to display this
>   information in all cases as the stats page could be often public.
> 
> ---
> changed in v2:
> - patch1/4: reorder parameters to match format string
> - patch3/4: reorder includes, error introduced while splitting my patch.
> 
> changed in v3:
> - reorg to allow build without USE_OPENSSL
> 
> changed in v4:
> - init SSL ctx at process startup at it could not work because SSL
>   functions are accessing filesystem
> - slightly change no-ssl keyword behaviour to allow SSL connection init,
>   when being used with a default-server ssl setting
> 
> changed in v5:
> - improve commit message of patch 1/2
> - add test for the new set server ssl command
> 
> William Dauchy (2):
>   MINOR: ssl: create common ssl_ctx init
>   MEDIUM: cli/ssl: configure ssl on server at runtime
> 
>  doc/configuration.txt |  4 ++
>  doc/management.txt|  4 ++
>  include/haproxy/server-t.h|  7 ++-
>  include/haproxy/ssl_sock.h|  1 +
>  .../checks/1be_40srv_odd_health_checks.vtc|  2 +-
>  .../checks/40be_2srv_odd_health_checks.vtc|  2 +-
>  reg-tests/checks/4be_1srv_health_checks.vtc   |  6 +-
>  reg-tests/server/cli_set_ssl.vtc  | 54 +
>  src/cfgparse-ssl.c| 59 +--
>  src/cfgparse.c|  9 ++-
>  src/proxy.c   |  5 +-
>  src/server.c  | 41 -
>  src/ssl_sock.c    | 17 ++
>  13 files changed, 165 insertions(+), 46 deletions(-)
>  create mode 100644 reg-tests/server/cli_set_ssl.vtc
> 

Thanks, now merged.

-- 
William Lallemand



Re: do we want to keep CentOS 6 builds?

2020-11-17 Thread William Lallemand
On Tue, Nov 17, 2020 at 12:16:05PM +0100, Willy Tarreau wrote:
> Hi all,
> 
> On Tue, Nov 17, 2020 at 12:10:41AM +0100, Lukas Tribus wrote:
> > No, but since we *only test* master, this is the only way we get
> > *some* coverage for the changes we are backporting to stable branches.
> > After all, a large percentage of them come from master. How do we know
> > that a fix that we are backporting to 1.8 won't break the build on an
> > older libc or gcc? There is a chance that this would have failed a
> > test on master.
> 
> I agree with the goal here. This is the same reason I occasionally
> run a build on an old AIX 5.2 system I have access to. I don't care
> if it works or not, I just want to see if I changed something without
> noticing. Many of the compiler optimization bugs for example can be
> triggered on older systems, the usual ctype bugs are revealed there as
> well, and many of the non-linux portability issues can be triggered on
> older libc as well. Trust me, I've been used to seeing haproxy being
> built on uncommon systems, and sometimes requiring a few tricks, but
> that's what people needed.
> 
> > I am very sympathetic to drop support for old systems, *if the
> > maintenance overhead becomes a burden* - and I don't set this bar
> > high.
> 
> Agreed. I'm in favor of no more than a few minutes a month if that
> still fits. When it becomes a pain (but then why?) we can drop it.
> I suggest however that we mark it as "allowed to fail" so that it's
> just indicative and we don't feel guilty not to address such issues
> quickly.


I agree with that, however the problem will be the test of features that
require an up to date version of OpenSSL, maybe we should improve the
script so we could at least exclude non-openssl and non-1.1.1 versions.

> > So, is this about OpenSSL?
> 
> By the way, RHEL6/CentOS6 are not the only ones affected by the OpenSSL
> 1.0.2 maintenance mess, there's Ubuntu 16.04 as well, which gets regular
> maintenance till April 2021 and extended maintenance till April 2024.
> And yes, I do want to see older versions of openssl continue to work as
> long as it doesn't come with too high a maintenance cost.
> 
It looks worse with CentOS, it uses a 1.0.1 release :-)

-- 
William Lallemand



Re: Use default/first crt only if all snifilter fails

2020-11-17 Thread William Lallemand
On Tue, Nov 17, 2020 at 09:18:43AM -0300, Joao Morais wrote:
> 
> 
> > Em 17 de nov de 2020, à(s) 05:28, William Lallemand 
> >  escreveu:
> > 
> > You could also do
> > 
> > /tmp/default.pem !*
> > 
> > That will ignore the creation of the SNI entries.
> 
> Wow thank you so much Willian, as far as I can tell and based on ~5min
> tests, this worked like a charm without any backward compatibility
> issue.
> 
> I consider this a nice addition to the doc that should be merged as
> far as the `!*` snifilter works. I can provide a patch if you consider
> this a feature instead of a hack, let me know if I can help.
> 

I agree that this should be documented, I never thought of this
usecase before but this is how the implementation works since the first
release containing the SNI filters! A patch is welcomed here!

Thanks.

-- 
William Lallemand



Re: Use default/first crt only if all snifilter fails

2020-11-17 Thread William Lallemand
On Tue, Nov 17, 2020 at 09:09:38AM +0100, William Lallemand wrote:
> On Mon, Nov 16, 2020 at 08:44:58PM -0300, Joao Morais wrote:
> > 
> > Hello list, I have a `crt-list` keyword configuring a list of
> > crt/keys, something like this:
> > 
> > /tmp/default.pem
> > /tmp/a.pema.local
> > /tmp/b.pemb.local
> > 
> > We consider the first line the fallback certificate - that one that
> > should be used if everything else fails.
> > 
> > We've however one situation where default.pem is valid for a.local,
> > and since default.pem is the first crt due to its fallback status,
> > default.pem is used in the handshake instead of a.pem.
> > 
> > Is there a way to configure a certificate to just act as a fallback
> > crt? Any other advice here?
> > 
> 
> Unfortunately no, there is no way of configuring a default certificate,
> it's always the first certificate declared on a bind line.
> 
> In practice the certificate is inserted in 2 places, the default_ctx and
> the SNI tree. The default_ctx does not use the filters so it will be
> always used as a fallback, however you can still sets a filter on this
> line so it rewrites its entries in the SNI tree without affecting the
> fallback.
> 
> /tmp/default.pem !a.local
> 
> should work on the first line.
> 
> Ideally we need a "crt-fallback" keyword which insert the crt in the
> default_ctx without inserting it in the SNI tree.
> 

You could also do

/tmp/default.pem !*

That will ignore the creation of the SNI entries.

-- 
William Lallemand



Re: Use default/first crt only if all snifilter fails

2020-11-17 Thread William Lallemand
On Mon, Nov 16, 2020 at 08:44:58PM -0300, Joao Morais wrote:
> 
> Hello list, I have a `crt-list` keyword configuring a list of
> crt/keys, something like this:
> 
> /tmp/default.pem
> /tmp/a.pema.local
> /tmp/b.pemb.local
> 
> We consider the first line the fallback certificate - that one that
> should be used if everything else fails.
> 
> We've however one situation where default.pem is valid for a.local,
> and since default.pem is the first crt due to its fallback status,
> default.pem is used in the handshake instead of a.pem.
> 
> Is there a way to configure a certificate to just act as a fallback
> crt? Any other advice here?
> 

Unfortunately no, there is no way of configuring a default certificate,
it's always the first certificate declared on a bind line.

In practice the certificate is inserted in 2 places, the default_ctx and
the SNI tree. The default_ctx does not use the filters so it will be
always used as a fallback, however you can still sets a filter on this
line so it rewrites its entries in the SNI tree without affecting the
fallback.

/tmp/default.pem !a.local

should work on the first line.

Ideally we need a "crt-fallback" keyword which insert the crt in the
default_ctx without inserting it in the SNI tree.

-- 
William Lallemand



[ANNOUNCE] haproxy-2.3.1

2020-11-13 Thread William Lallemand
Hi,

HAProxy 2.3.1 was released on 2020/11/13. It added 26 new commits
after version 2.3.0.

This is the first release since the 2.3.0 of last week and it fixes a few
bugs:

Chistopher fixed a memory corruption in the spoe which appears when an
offloaded stream try to update the state of a released applet because it still
have a reference on it. There are many ways to trigger this bug. The easiest
is probably during reloads.

The crt-list support was partly broken, which led to some crt-list lines
silently ignored in the case the certificate they use was already used on
another line. (issue #940)

Willy fixed a decoding problem in the peers implementation which was leading
to protocol errors.

Amaury fixed a problem in the checks which could lead to a segfault.
(issue #945)

Less critical fixes are listed in the changelog below.

As usual, please update to this version if you are using the 2.3.0.


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
   Wiki : https://github.com/haproxy/wiki/wiki
   Sources  : http://www.haproxy.org/download/2.3/src/
   Git repository   : http://git.haproxy.org/git/haproxy-2.3.git/
   Git Web browsing : http://git.haproxy.org/?p=haproxy-2.3.git
   Changelog: http://www.haproxy.org/download/2.3/src/CHANGELOG
   Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/


---
Complete changelog :
Amaury Denoyelle (4):
  BUG/MINOR: stats: free dynamically stats fields/lines on shutdown
  BUG/MEDIUM: check: reuse srv proto only if using same mode
  MINOR: check: report error on incompatible proto
  MINOR: check: report error on incompatible connect proto

Christopher Faulet (10):
  MINOR: http-htx: Add understandable errors for the errorfiles parsing
  DOC: config: Fix a typo on ssl_c_chain_der
  BUG/MINOR: http-fetch: Fix calls w/o parentheses of the cookie sample 
fetches
  BUG/MINOR: http-htx: Handle warnings when parsing http-error and 
http-errors
  BUG/MAJOR: spoe: Be sure to remove all references on a released spoe 
applet
  MINOR: spoe: Don't close connection in sync mode on processing timeout
  BUG/MINOR: tcpcheck: Don't warn on unused rules if check option is after
  MINOR: init: Fix the prototype for per-thread free callbacks
  MINOR: config/mux-h2: Return ERR_ flags from init_h2() instead of a status
  REGTEST: make ssl_client_samples and ssl_server_samples require to 2.2

Eric Salama (1):
  MINOR: cfgparse: tighten the scope of newnameserver variable, free it on 
error.

Frédéric Lécaille (3):
  BUG/MINOR: peers: Do not ignore a protocol error for dictionary entries.
  BUG/MINOR: peers: Missing TX cache entries reset.
  MINOR: peers: Add traces to peer_treat_updatemsg().

Maciej Zdeb (1):
  BUG/MINOR: http-fetch: Extract cookie value even when no cookie name

Thierry Fournier (2):
  BUG/MINOR: pattern: a sample marked as const could be written
  BUG/MINOR: lua: set buffer size during map lookups

William Lallemand (3):
  BUG/MEDIUM: ssl/crt-list: correctly insert crt-list line if crt already 
loaded
  REGTEST: ssl: test wildcard and multi-type + exclusions
  REGTEST: ssl: mark reg-tests/ssl/ssl_crt-list_filters.vtc as broken

Willy Tarreau (2):
  BUG/MINOR: ssl: don't report 1024 bits DH param load error when it's 
higher
  BUG/MEDIUM: peers: fix decoding of multi-byte length in stick-table 
messages

-- 
William Lallemand



Re: [PATCH v4 2/2] MEDIUM: cli/ssl: configure ssl on server at runtime

2020-11-11 Thread William Lallemand
On Thu, Oct 29, 2020 at 01:17:56PM +0100, William Dauchy wrote:
> in the context of a progressive backend migration, we want to be able to
> activate SSL on outgoing connections to the server at runtime without
> reloading.
> This patch adds a `set server ssl` command; in order to allow that:
> 
> - add `srv_use_ssl` to `show servers state` command for compatibility,
>   also update associated parsing
> - when using default-server ssl setting, and `no-ssl` on server line,
>   init SSL ctx without activating it
> - when triggering ssl API, de/activate SSL connections as requested
> - clean ongoing connections as it is done for addr/port changes, without
>   checking prior server state
> 
> example config:
> 
> backend be_foo
>   default-server ssl
>   server srv0 127.0.0.1:6011 weight 1 no-ssl
> 
> show servers state:
> 
>   5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1
> 
> where srv0 can switch to ssl later during the runtime:
> 
>   set server be_foo/srv0 ssl on
> 
>   5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1
> 
> Signed-off-by: William Dauchy 


Looks good. I think a VTC file which tests this feature could
also be a good idea, so we don't break this accidentaly.

Thanks!

-- 
William Lallemand



Re: [PATCH v4 1/2] MINOR: ssl: create common ssl_ctx init

2020-11-11 Thread William Lallemand
On Thu, Oct 29, 2020 at 01:17:55PM +0100, William Dauchy wrote:
> so we can reuse it later
> 
> Signed-off-by: William Dauchy 


Could you add a little more explanations in the commit message for this
one, and separate clearly the subject from the commit message?

Thanks!

-- 
William Lallemand



Re: Updated CI using GitHub actions

2020-11-10 Thread William Lallemand
On Tue, Nov 10, 2020 at 10:30:52PM +0100, Tim Düsterhus wrote:
> Let me (or Ilya) know if you have any questions or if you notice any
> issues with it. Personally I'm super happy with how it turned out :-)
> 

Thanks to both of you, the whole thing is cleaner and quicker from my
point of view :-)

-- 
William Lallemand



Re: [ANNOUNCE] haproxy-2.3.0

2020-11-06 Thread William Lallemand
On Thu, Nov 05, 2020 at 07:20:46PM +0100, Willy Tarreau wrote:
> Hi,
> 
> HAProxy 2.3.0 was released on 2020/11/05. It added 33 new commits after
> version 2.3-dev9. I was right to wait a few more days before releasing,
> we could spot two late regressions and fix them in time!
> 

Hi,

The crt-list support of this version is partly broken, lines are
silently ignored if they uses a certificate which was already loaded.

A fix was pushed today in the git:

https://git.haproxy.org/?p=haproxy-2.3.git;a=commit;h=689d981541a4805760acd6a2ba1433dc3d3534b1

Distribution maintainers should consider this one if they didn't emit
the 2.3.0 yet. 

We'll probably make a 2.3.1 release at the end of next week.

Sorry for the mess!

-- 
William Lallemand



Re: [PATCH] check ssl keylog by feature, not by version defined

2020-11-03 Thread William Lallemand
On Tue, Nov 03, 2020 at 02:19:10PM +0500, Илья Шипицин wrote:
> Hi,
> 
> the less we use HA_OPENSSL_VERSION_NUMBER, the better.
> 
> cheers,
> Ilya

Thanks, merged in master.

-- 
William Lallemand



Re: [ANNOUNCE] haproxy-2.3-dev9

2020-11-03 Thread William Lallemand
On Tue, Nov 03, 2020 at 01:59:35PM +0500, Илья Шипицин wrote:
> > > also, couple of reg-tests fail on openssl no-deprecated mode
> > > https://github.com/haproxy/haproxy/issues/924
> > >
> >
> > I don't know about this one, I'll need to test that locally, I never
> > linked haproxy with the no-deprecated mode before, I don't even know if
> >
> 
I can reproduce that on my laptop with OpenSSL 1.1.1g, no need to set
the no deprecated mode.

-- 
William Lallemand



Re: [ANNOUNCE] haproxy-2.3-dev9

2020-11-03 Thread William Lallemand
On Mon, Nov 02, 2020 at 05:17:53PM +0500, Илья Шипицин wrote:
> сб, 31 окт. 2020 г. в 17:53, Willy Tarreau :
> 
> > Hi,
> >
> > HAProxy 2.3-dev9 was released on 2020/10/31. It added 27 new commits
> > after version 2.3-dev8.
> >
> > Things have cooled down quite a bit, I really appreciate it. To be
> > honest, I've really been hesitating between releasing 2.3-final now
> > or leaving one extra week. Finally, considering that we're not late
> > and that the last fixed issues were recently reported, I considered
> > that it was worth waiting one more week to confirm this encouraging
> > trend.
> >
> 
> freebsd builds are unstable
> https://github.com/haproxy/haproxy/runs/1341524534
> 

That one is strange, it looked like the proxy protocol is working since
there are others tests which use it that works. However this is the only
test in the reg-test suite using "unix@" maybe the issue is here, or a
combination of the two.

> also, couple of reg-tests fail on openssl no-deprecated mode
> https://github.com/haproxy/haproxy/issues/924
>

I don't know about this one, I'll need to test that locally, I never
linked haproxy with the no-deprecated mode before, I don't even know if
every haproxy features are supported with this mode.

> 
> should we address those failures before 2.3 release ?
> 

It's better if we can fix the FreeBSD issue and at least identify what
the problems are with the openSSL issue.

-- 
William Lallemand



Re: [PATCH] improve openssl feature detection

2020-11-03 Thread William Lallemand
On Sat, Oct 31, 2020 at 02:13:35AM +0500, Илья Шипицин wrote:
> hi,
> 
> let us use SSL_CTRL_GET_RAW_CIPHERLIST instead of versions.
> 
> cheers,
> Ilya

Thanks, pushed in master.

-- 
William Lallemand



Re: [PATCH 0/2] Cache fixes

2020-10-27 Thread William Lallemand
Hello Tim,

On Thu, Oct 22, 2020 at 09:15:04PM +0200, Tim Duesterhus wrote:
> William,
> Rémi,
> 
> I'm super happy to see that the support for if-none-match made it into 2.3. I
> already was considering poking under some of the recent -devX announcements,
> but thought it already was too late for it and thus did not.
> 
> Consider taking the following patches:
> 
> - CLEANUP: This one probably can be argued about. I thought that the previous
>implementation did not really fit HAProxy's code style, it felt
>very unnatural to me. But of course that's personal preferences.

In my opinion the code is readable enough, I'll skip your patch because it's
really personal preferences.

> - BUG/MINOR: This was something Christopher noted during review of my earlier
>  series. The adjustment of the status code is probably failing
>  roughly never, but I guess it's better to be safe there.
> 

I think the impact is reasonable here, I'll take this one.

Thanks!

-- 
William Lallemand



Re: [PATCH] update h2spec to 2.6.0

2020-10-27 Thread William Lallemand
On Sun, Oct 25, 2020 at 07:37:16PM +0500, Илья Шипицин wrote:
> Hi,
> 
> we missed couple of releases.
> 
> Ilya


Merged, thanks.

-- 
William Lallemand



Re: [PATCH] refactor specific openssl early data detection check

2020-10-27 Thread William Lallemand
On Sat, Oct 24, 2020 at 11:51:57PM +0500, Илья Шипицин wrote:
> Hi,
> 
> "#ifdef SSL_READ_EARLY_DATA_SUCCESS" seem to be better
> than version based check.
> 
> it is preparation to unlocking BoringSSL 1.1.1 compatibility version.
> 
> 
> 
> cheers,
> Ilya


Totally agree with this, merged in master.


-- 
William Lallemand



Re: [PATCH] BUG/MEDIUM: ssl: OCSP must work with BoringSSL

2020-10-27 Thread William Lallemand
On Mon, Oct 26, 2020 at 02:32:20PM +0100, ehoc...@club-internet.fr wrote:
> ‌‌Hi,
> 
> It's a fix for a regression with OCSP and BoringSSL.
> OCSP work with BorginSSL, not at the same way than openssl, but it work:
> OCSP data is simply link to CTX context.
> 
> ++
> Manu
> 
> 
> 


Thanks, pushed in master and backported in 2.2 and 2.1!


-- 
William Lallemand



Re: stable-bot: Bugfixes waiting for a release 2.2 (20), 2.1 (16), 2.0 (15), 1.8 (20)

2020-10-22 Thread William Lallemand
On Thu, Oct 22, 2020 at 08:41:35PM +0200, William Lallemand wrote:
> On Thu, Oct 22, 2020 at 10:20:12PM +0500, Илья Шипицин wrote:
> > can we backport
> > http://git.haproxy.org/?p=haproxy.git;a=commit;h=b3201a3e077198b3f75ebe8661aa45589b811552
> > to 2.1 as well ? it was not scheduled, but it is required to fix BoringSSL
> > builds
> >
> 
> BoringSSL does not have any maintenance branches and they encourage to
> have the boringSSL code shipped with the programs that use it.
> 
> That's why we shouldn't spend much time doing boringSSL maintenance in
> older branches, it does not make much sens to me. Or we will spend our
> time fixing boringSSL build for old versions each time they change their
> API. That's not how a stable branch is supposed to work.
> 
> Since people using boringSSL does not use a boringSSL release, I don't
> see why they would need a haproxy release :-)
> 

I just backported both patches as the conflicts were quite simple to
resolve.

-- 
William Lallemand



Re: stable-bot: Bugfixes waiting for a release 2.2 (20), 2.1 (16), 2.0 (15), 1.8 (20)

2020-10-22 Thread William Lallemand
On Thu, Oct 22, 2020 at 10:20:12PM +0500, Илья Шипицин wrote:
> can we backport
> http://git.haproxy.org/?p=haproxy.git;a=commit;h=b3201a3e077198b3f75ebe8661aa45589b811552
> to 2.1 as well ? it was not scheduled, but it is required to fix BoringSSL
> builds
>

BoringSSL does not have any maintenance branches and they encourage to
have the boringSSL code shipped with the programs that use it.

That's why we shouldn't spend much time doing boringSSL maintenance in
older branches, it does not make much sens to me. Or we will spend our
time fixing boringSSL build for old versions each time they change their
API. That's not how a stable branch is supposed to work.

Since people using boringSSL does not use a boringSSL release, I don't
see why they would need a haproxy release :-)

-- 
William Lallemand



Re: [PATCH] update trvis-ci to Ubuntu 20.04

2020-10-22 Thread William Lallemand
Hello Ilya,

On Wed, Oct 21, 2020 at 03:15:13PM +0500, Илья Шипицин wrote:
>apt:
>  update: true
> -packages: [ liblua5.3-dev, libsystemd-dev, libpcre2-dev, clang-9, socat, 
> ninja-build ]
> +packages: [ liblua5.3-dev, libsystemd-dev, libpcre2-dev, clang-9, socat, 
> ninja-build, libpcre3-dev ]
>

Is there a reason we need both libprcre packages?


-- 
William Lallemand



  1   2   3   4   5   6   >