Re: [ANNOUNCE] haproxy-2.5-dev13

2021-11-17 Thread Илья Шипицин
thanks, all coverity issues were resolved :)

[image: image.png]

вс, 7 нояб. 2021 г. в 16:27, Илья Шипицин :

> as we are close to 2.5, can the following remaining Coverity issues be
> addressed ? at least I'm aware of possible null pointer deref
>
> src/stream_interface.c: insecure data handling suspected by coverity ·
> Issue #1405 · haproxy/haproxy (github.com)
> 
>
> src/stick_table.c: unchecked return value suspected by coverity · Issue
> #1163 · haproxy/haproxy (github.com)
> 
>
> Null pointer dereference suspected by coverity · Issue #1434 ·
> haproxy/haproxy (github.com)
> 
>
> сб, 6 нояб. 2021 г. в 14:11, Willy Tarreau :
>
>> Hi,
>>
>> HAProxy 2.5-dev13 was released on 2021/11/06. It added 35 new commits
>> after version 2.5-dev12.
>>
>> These are the last-mile fixes and cleanups for this release.
>>
>>   - the backend support for WebSocket over HTTP/2 was adjusted to allow
>> WebSocket to use HTTP/1 even if HTTP traffic uses HTTP/2. There were
>> indeed some users complaining about broken WebSocket when H2 is
>> enabled on the backend side because their servers did not yet support
>> WebSocket over HTTP/2. With this, haproxy will offer WS over HTTP/2
>> even if the server runs HTTP/2 without it, and haproxy will use HTTP/1
>> connections to the server for WS. The new server keyword to tune this
>> is "ws". This part will be backported to 2.4 to fix the issues that
>> these users are facing. More improvements are planned (autodetection)
>> but they do present certain shortcomings in case servers would restart
>> and change their status, so they were kept on hold for now.
>>
>>   - the fc_conn_err and bc_conn_err sample fetch functions which return
>> the
>> frontend connection and backend connection error codes were renamed to
>> "fc_err" and "bc_err" to be consistent with the other ones, as "fc"
>> and
>> "bc" already stand for "frontend connection" and "backend connection".
>> No need for the confusing redundancy. This may possibly break some
>> configs if you were using them on a development version, but better
>> fix
>> that before they're part of a final release.
>>
>>   - as discussed a few days ago, the frontend connection's SNI was added
>> to
>> the HTTPS log format. It was placed just before the SSL version and
>> ciphers, delimited with a '/' so that even if an empty one is sent,
>> there is no ambiguity on the field parsing.
>>
>>   - some of the DNS stats counters were split into their own resolvers
>> stats, because they were really resolver events rather than DNS
>> protocol level events. This could make a difference when we later
>> implement support for DNS load balancing.
>>
>>   - a warning is now sent when "compression offload" is used in a defaults
>> section, because that does nothing. While the doc was already clear
>> about it, it used to be accepted by the config parser, so we cannot
>> really error on it now at the risk of breaking some harmless configs.
>> However a warning does seem appropriate at least.
>>
>>   - small fixes and updates on JWT, resolvers, and QUIC
>>
>>   - build instructions for QUIC and quictls were added to the INSTALL file
>>
>>   - an example error-log-format was added to the doc, as it wasn't exactly
>> trivial. We think it covers most use cases, so with a bit of luck it
>> will often be copy-pasted and generalized.
>>
>>   - more code cleanups, doc updates, and regtest cleanups
>>
>> Yesterday while reviewing optimal logging options for HTTPS with William,
>> we noticed that some sample-fetch functions are missing to retrieve the
>> certificate check status on the backend, or extract the backend's TLS
>> version or SNI. The code already exists (we even did most of it on the
>> fly just to test) but I didn't want to rush a last-minute set of new
>> sample-fetch functions, whose tests and documentation would needlessly
>> delay this release. I will probably add them later next week or after the
>> release, and they're low-importance details that can trivially be
>> backported if we want.
>>
>> I've told Björn not to rush his patches on Multi-path TCP. While they're
>> trivial and certainly harmless, there's no reason to hurry on this at the
>> last minute and risk to make mistakes, we'll have plenty of time to
>> complete
>> this work later. MPTCP is still young, and if there's some demand, once
>> merged the backport should even be trivial to perform.
>>
>> I expect a few more doc updates, makefile reorderings/cleanups, regtests,
>> bug fixes, maybe a few more sample-fetch functions and converters, some
>> more tests on various machine sizes, and if everything's good we could
>> release by the end of next week.
>>
>> So, please test it. If you can't take any risk on your production, at the
>> v

Re: [ANNOUNCE] haproxy-2.5-dev13

2021-11-07 Thread Илья Шипицин
as we are close to 2.5, can the following remaining Coverity issues be
addressed ? at least I'm aware of possible null pointer deref

src/stream_interface.c: insecure data handling suspected by coverity ·
Issue #1405 · haproxy/haproxy (github.com)


src/stick_table.c: unchecked return value suspected by coverity · Issue
#1163 · haproxy/haproxy (github.com)


Null pointer dereference suspected by coverity · Issue #1434 ·
haproxy/haproxy (github.com)


сб, 6 нояб. 2021 г. в 14:11, Willy Tarreau :

> Hi,
>
> HAProxy 2.5-dev13 was released on 2021/11/06. It added 35 new commits
> after version 2.5-dev12.
>
> These are the last-mile fixes and cleanups for this release.
>
>   - the backend support for WebSocket over HTTP/2 was adjusted to allow
> WebSocket to use HTTP/1 even if HTTP traffic uses HTTP/2. There were
> indeed some users complaining about broken WebSocket when H2 is
> enabled on the backend side because their servers did not yet support
> WebSocket over HTTP/2. With this, haproxy will offer WS over HTTP/2
> even if the server runs HTTP/2 without it, and haproxy will use HTTP/1
> connections to the server for WS. The new server keyword to tune this
> is "ws". This part will be backported to 2.4 to fix the issues that
> these users are facing. More improvements are planned (autodetection)
> but they do present certain shortcomings in case servers would restart
> and change their status, so they were kept on hold for now.
>
>   - the fc_conn_err and bc_conn_err sample fetch functions which return the
> frontend connection and backend connection error codes were renamed to
> "fc_err" and "bc_err" to be consistent with the other ones, as "fc" and
> "bc" already stand for "frontend connection" and "backend connection".
> No need for the confusing redundancy. This may possibly break some
> configs if you were using them on a development version, but better fix
> that before they're part of a final release.
>
>   - as discussed a few days ago, the frontend connection's SNI was added to
> the HTTPS log format. It was placed just before the SSL version and
> ciphers, delimited with a '/' so that even if an empty one is sent,
> there is no ambiguity on the field parsing.
>
>   - some of the DNS stats counters were split into their own resolvers
> stats, because they were really resolver events rather than DNS
> protocol level events. This could make a difference when we later
> implement support for DNS load balancing.
>
>   - a warning is now sent when "compression offload" is used in a defaults
> section, because that does nothing. While the doc was already clear
> about it, it used to be accepted by the config parser, so we cannot
> really error on it now at the risk of breaking some harmless configs.
> However a warning does seem appropriate at least.
>
>   - small fixes and updates on JWT, resolvers, and QUIC
>
>   - build instructions for QUIC and quictls were added to the INSTALL file
>
>   - an example error-log-format was added to the doc, as it wasn't exactly
> trivial. We think it covers most use cases, so with a bit of luck it
> will often be copy-pasted and generalized.
>
>   - more code cleanups, doc updates, and regtest cleanups
>
> Yesterday while reviewing optimal logging options for HTTPS with William,
> we noticed that some sample-fetch functions are missing to retrieve the
> certificate check status on the backend, or extract the backend's TLS
> version or SNI. The code already exists (we even did most of it on the
> fly just to test) but I didn't want to rush a last-minute set of new
> sample-fetch functions, whose tests and documentation would needlessly
> delay this release. I will probably add them later next week or after the
> release, and they're low-importance details that can trivially be
> backported if we want.
>
> I've told Björn not to rush his patches on Multi-path TCP. While they're
> trivial and certainly harmless, there's no reason to hurry on this at the
> last minute and risk to make mistakes, we'll have plenty of time to
> complete
> this work later. MPTCP is still young, and if there's some demand, once
> merged the backport should even be trivial to perform.
>
> I expect a few more doc updates, makefile reorderings/cleanups, regtests,
> bug fixes, maybe a few more sample-fetch functions and converters, some
> more tests on various machine sizes, and if everything's good we could
> release by the end of next week.
>
> So, please test it. If you can't take any risk on your production, at the
> very least please check that it properly loads your configuration and/or
> that any warning or error is expected, that could save you some precious
> time later ;-)
>
> Please find the usual URLs below :
>Site index   : ht

[ANNOUNCE] haproxy-2.5-dev13

2021-11-06 Thread Willy Tarreau
Hi,

HAProxy 2.5-dev13 was released on 2021/11/06. It added 35 new commits
after version 2.5-dev12.

These are the last-mile fixes and cleanups for this release.

  - the backend support for WebSocket over HTTP/2 was adjusted to allow
WebSocket to use HTTP/1 even if HTTP traffic uses HTTP/2. There were
indeed some users complaining about broken WebSocket when H2 is
enabled on the backend side because their servers did not yet support
WebSocket over HTTP/2. With this, haproxy will offer WS over HTTP/2
even if the server runs HTTP/2 without it, and haproxy will use HTTP/1
connections to the server for WS. The new server keyword to tune this
is "ws". This part will be backported to 2.4 to fix the issues that
these users are facing. More improvements are planned (autodetection)
but they do present certain shortcomings in case servers would restart
and change their status, so they were kept on hold for now.

  - the fc_conn_err and bc_conn_err sample fetch functions which return the
frontend connection and backend connection error codes were renamed to
"fc_err" and "bc_err" to be consistent with the other ones, as "fc" and
"bc" already stand for "frontend connection" and "backend connection".
No need for the confusing redundancy. This may possibly break some
configs if you were using them on a development version, but better fix
that before they're part of a final release.

  - as discussed a few days ago, the frontend connection's SNI was added to
the HTTPS log format. It was placed just before the SSL version and
ciphers, delimited with a '/' so that even if an empty one is sent,
there is no ambiguity on the field parsing.

  - some of the DNS stats counters were split into their own resolvers
stats, because they were really resolver events rather than DNS
protocol level events. This could make a difference when we later
implement support for DNS load balancing.

  - a warning is now sent when "compression offload" is used in a defaults
section, because that does nothing. While the doc was already clear
about it, it used to be accepted by the config parser, so we cannot
really error on it now at the risk of breaking some harmless configs.
However a warning does seem appropriate at least.

  - small fixes and updates on JWT, resolvers, and QUIC

  - build instructions for QUIC and quictls were added to the INSTALL file

  - an example error-log-format was added to the doc, as it wasn't exactly
trivial. We think it covers most use cases, so with a bit of luck it
will often be copy-pasted and generalized.

  - more code cleanups, doc updates, and regtest cleanups

Yesterday while reviewing optimal logging options for HTTPS with William,
we noticed that some sample-fetch functions are missing to retrieve the
certificate check status on the backend, or extract the backend's TLS
version or SNI. The code already exists (we even did most of it on the
fly just to test) but I didn't want to rush a last-minute set of new
sample-fetch functions, whose tests and documentation would needlessly
delay this release. I will probably add them later next week or after the
release, and they're low-importance details that can trivially be
backported if we want.

I've told Björn not to rush his patches on Multi-path TCP. While they're
trivial and certainly harmless, there's no reason to hurry on this at the
last minute and risk to make mistakes, we'll have plenty of time to complete
this work later. MPTCP is still young, and if there's some demand, once
merged the backport should even be trivial to perform.

I expect a few more doc updates, makefile reorderings/cleanups, regtests,
bug fixes, maybe a few more sample-fetch functions and converters, some
more tests on various machine sizes, and if everything's good we could
release by the end of next week.

So, please test it. If you can't take any risk on your production, at the
very least please check that it properly loads your configuration and/or
that any warning or error is expected, that could save you some precious
time later ;-)

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

Willy
---
Complete changelog :
Amaury Denoyelle (8):
  MINOR: mux-h2: add trace on extended connect usage
  BUG/MEDIUM: mux-h2: reject upgrade if no RFC8441 support
  MINOR: stream/mux: implement websocket stream fla