IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Add new quic_cstream struct definition to implement the CRYPTO data stream.
This is a simplication of the qcs object (QUIC streams) for the CRYPTO data
without any information about the flow control. They are not attached to any
tree, but to a QUIC encryption level, one by encryption level except for
the early data encryption level (for 0RTT). A stream descriptor is also allocated
for each CRYPTO data stream.
Must be backported to 2.6
(cherry picked from commit 7e3f7c47e9acdf074c678cdee4202192fffb7de4)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
In the past we've seen "show servers state" dump some internal bits for
the check states, that were causing regtests to fail. The relevant bits
have been added to the doc to fix the public API and make sure they do
not change by accident, but the output doesn't take care of masking the
undesired ones, causing regtests (and possibly user programs) to fail
when new bits are added. Let's add the mask for the only documented ones
(0x0F for check and 0x1F for agent respectively).
This could be backported wherever the server state is present, though
there's a tiny risk that some undocumented bits might have already
leaked to some user scripts, so it might be wise to wait a bit before
doing that or even not to backport too far.
(cherry picked from commit 99521abd59a255538f2f9a64d3379c31aef5a630)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Since commit 03cdf55e6 ("MINOR: stream: Stickiness server lookup by name.")
in 2.0-dev6, server names may be used instead of their IDs, in order to
perform stickiness. However the commit above may end up trying to insert
an empty server name in the dictionary when the server is an applet
instead, resulting in an immediate segfault. This is typically what
happens when a "stick-store" rule is present in a backend featuring a
"stats" directive. As there doesn't seem to be an easy way around it,
it seems to imply that "stick-store" is not much used anymore.
The solution here is to only try to insert non-null keys into the
dictionary. The patch moves the check of the key type before the
first lock so that the test on the key can be performed under the lock
instead of locking twice (the patch is more readable with diff -b).
Note that before 2.4, there's no <key> variable there as it was
introduced by commit 92149f9a8 ("MEDIUM: stick-tables: Add srvkey
option to stick-table"), but the __objt_server(s->target)->id still
needs to be tested.
This needs to be backported as far as 2.0.
(cherry picked from commit bc7c207f745bf6406b38139b98cb5b8c794e13f0)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
An example given for tcp-request content rule with lua
was missing 'if' keyword. Using it "as is" makes haproxy unhappy.
The example was introduced with 579d83b05.
So it may be backported as far as 1.6, but it is a really minor typo.
(cherry picked from commit d49b559a15a8781ba37877812d4d3ddf2cea9eb4)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Move code which activates IP_PKTINFO socket option (or affiliated
options) from sock_inet_bind_receiver() to quic_bind_listener()
function. This change is useful for two reasons :
* first, and the most important one : this activates IP_PKTINFO only for
QUIC receivers. The previous version impacted all datagram receivers,
used for example by log-forwarder. This should reduce memory usage for
these datagram sockets which do not need this option.
* second, USE_QUIC preprocessor statements are removed from
src/sock_inet.c which clean up the code.
IP_PKTINFO was introduced recently by the following patch :
97ecc7a8ea5339a753507c3d4e4cd83028c6d038 (quic-dev/qns)
MEDIUM: quic: retrieve frontend destination address
For the moment, this does not impact any stable release. However, as
previous patch is scheduled for 2.6 backporting, the current change must
also be backported to the same versions.
(cherry picked from commit 487d04f6d7410059b44b69d56c53be7802963bab)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
The tx_qrings[] and tx_qring_list in the receiver are not used
anymore since commit f2476053f ("MINOR: quic: replace custom buf on Tx
by default struct buffer"), the only place where they're referenced
was in quic_alloc_tx_rings_listener(), which by the way implies that
these were not even freed on exit.
Let's just remove them. This should be backported to 2.6 since the
commit above also was.
(cherry picked from commit cab054bbf9908f3732648e5236d889650a6e33f7)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Retrieve the frontend destination address for a QUIC connection. This
address is retrieve from the first received datagram and then stored in
the associated quic-conn.
This feature relies on IP_PKTINFO or affiliated flags support on the
socket. This flag is set for each QUIC listeners in
sock_inet_bind_receiver(). To retrieve the destination address,
recvfrom() has been replaced by recvmsg() syscall. This operation and
parsing of msghdr structure has been extracted in a wrapper quic_recv().
This change is useful to finalize the implementation of 'dst' sample
fetch. As such, quic_sock_get_dst() has been edited to return local
address from the quic-conn. As a best effort, if local address is not
available due to kernel non-support of IP_PKTINFO, address of the
listener is returned instead.
This should be backported up to 2.6.
(cherry picked from commit 97ecc7a8ea5339a753507c3d4e4cd83028c6d038)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Previous commit 8a6767d26 ("BUG/MINOR: config: don't count trailing spaces
as empty arg (v2)") was still not enough. As reported by ClusterFuzz in
issue 52049 (https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=52049),
there remains a case where for the sake of reporting the correct argument
count, the function may produce virtual args that span beyond the end of
the output buffer if that one is too short. That's what's happening with
a config file of one empty line followed by a large number of args.
This means that what args[] points to cannot be relied on and that a
different approach is needed. Since no output is produced for spaces and
comments, we know that args[arg] continues to point to out+outpos as long
as only comments or spaces are found, which is what we're interested in.
As such it's safe to check the last arg's pointer against the one before
the trailing zero was emitted, in order to decide to count one final arg.
No backport is needed, unless the commit above is backported.
(cherry picked from commit 94ab139266a2d2d39f7254644f69fb699559e8e2)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
In parse_line(), spaces increment the arg count and it is incremented
again on '#' or end of line, resulting in an extra empty arg at the
end of arg's list. The visible effect is that the reported arg count
is in excess of 1. It doesn't seem to affect regular function but
specialized ones like anonymisation depends on this count.
This is the second attempt for this problem, here the explanation :
When called for the first line, no <out> was allocated yet so it's NULL,
letting the caller realloc a larger line if needed. However the words are
parsed and their respective args[arg] are filled with out+position, which
means that while the first arg is NULL, the other ones are no and fail the
test that was meant to avoid dereferencing a NULL. Let's simply check <out>
instead of <args> since the latter is always derived from the former and
cannot be NULL without the former also being.
This may need to be backported to stable versions.
(cherry picked from commit 8a6767d266e0b885d1752a99cbe6b1e11c4e4256)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
At present option smtpchk closes the TCP connection abruptly on completion of service checking,
even if successful. This can result in a very high volume of errors in backend SMTP server logs.
This patch ensures an SMTP QUIT is sent and a positive 2xx response is received from the SMTP
server prior to disconnection.
This patch depends on the following one:
* MINOR: smtpchk: Update expect rule to fully match replies to EHLO commands
This patch should fix the issue #1812. It may be backported as far as 2.2
with the commit above On the 2.2, proxy_parse_smtpchk_opt() function is
located in src/check.c
[cf: I updated reg-tests script accordingly]
(cherry picked from commit 9a8d8a3fd0828a1cb64745318dcc5704a0b4b1a9)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
The response to EHLO command is a multiline reply. However the corresponding
expect rule only match on the first line. For now, it is not an issue. But
to be able to send the QUIT command and gracefully close the connection, we
must be sure to consume the full EHLO reply first.
To do so, the regex has been updated to match all 2xx lines at a time.
(cherry picked from commit 2ec1ffaed061cd3560934c7525b204dbca25ace3)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
The commit 372b38f935 ("BUG/MEDIUM: mux-h1: Handle connection error after a
synchronous send") introduced a bug. In h1_snd_buf(), consumed data are not
properly accounted if a connection error is detected. Indeed, data are
consumed when the output buffer is filled. But, on connection error, we exit
from the loop without incremented total variable accordingly.
When this happens, this leaves the channel buffer in an inconsistent
state. The buffer may be empty with some output at the channel level.
Because an error is reported, it is harmless. But it is safer to fix this
bug now to avoid any regression in future.
This patch must be backported as far as 2.2.
(cherry picked from commit b0b8e9bbd2b720ed2aff469d0989ce00876007dc)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Fix some indentation in qc_lstnr_pkt_rcv().
This should be backported up to 2.6.
(cherry picked from commit 90121b3321512a74df1a5349c0f99fa2ccd0c017)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Inspect return code of qc_send_mux(). If quic-conn layer reports an
error, this will interrupt the current emission process.
This should be backported up to 2.6.
(cherry picked from commit 036cc5d88061a05442183d243d07604f696537b5)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Continue on the cleanup of QUIC stack and components.
quic_conn uses internally a ssl_sock_ctx to handle mandatory TLS QUIC
integration. However, this is merely as a convenience, and it is not
equivalent to stackable ssl xprt layer in the context of HTTP1 or 2.
To better emphasize this, ssl_sock_ctx usage in quic_conn has been
removed wherever it is not necessary : namely in functions not related
to TLS. quic_conn struct now contains its own wait_event for tasklet
quic_conn_io_cb().
This should be backported up to 2.6.
(cherry picked from commit 2ed840015f2d7ca37af77c0d9808cac3b0441d40)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Channel.insert(channel, string, [,offset]):
When no offset is provided, hlua_channel_insert_data() inserts
string at the end of incoming data.
This behavior conflicts with the documentation that explicitly says
that the default behavior is to insert the string in front of incoming data.
This patch fixes hlua_channel_insert_data() behavior so that it fully
complies with the documentation.
Thanks to Smackd0wn for noticing it.
This could be backported to 2.6 and 2.5
(cherry picked from commit afb7dafb44d240c9c306a41905812a40d700086c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Gcc 4.x, 5.x and 6.x report this when compiling http_fetch.c:
src/http_fetch.c: In function 'smp_fetch_meth':
src/http_fetch.c:357:6: warning: 'htx' may be used uninitialized in this function [-Wmaybe-uninitialized]
sl = http_get_stline(htx);
That's quite weird since there's no such code path, but presetting the
htx variable to NULL during declaration is enough to shut it up.
This may be backported to any version that has dbbdb25f1 ("BUG/MINOR:
http-fetch: Use integer value when possible in "method" sample fetch")
as it's the one that triggered this warning (hence at least 2.0).
(cherry picked from commit 2e2b79d157944d12922ae7ad487247259f3e6d70)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
In smp_fetch_meth(), smp_prefetch_htx() function may be called to parse the
HTX message and update the HTTP transaction accordingly. In this case, in
smp_fetch_metch() and on success, we must update "meth" variable. Otherwise,
the variable is still equal to HTTP_METH_OTHER and the string version is
always used instead of the enum for known methods.
This patch must be backported as far as 2.0.
(cherry picked from commit eefcd8a97de7d1b05b38d240b1061e2f2112f2f8)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
As seen in issue #1866, some environments will not allow to change the
current FD limit, and actually we don't need to do it, we only do it as
a byproduct of adjusting the limit to the one that fits. Here we're
replacing calls to setrlimit() with calls to raise_rlim_nofile(), which
will avoid making the setrlimit() syscall in case the desired value is
lower than the current process' one.
This depends on previous commit "MINOR: fd: add a new function to only
raise RLIMIT_NOFILE" and may need to be backported to 2.6, possibly
earlier, depending on users' experience in such environments.
(cherry picked from commit c06557c23b0e4e932405fe3f0739c303ac90926e)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
In issue #1866 an issue was reported under docker, by which a user cannot
lower the number of FD needed. It looks like a restriction imposed in this
environment, but it results in an error while it ought not have to in the
case of shrinking.
This patch adds a new function raise_rlim_nofile() that takes the desired
new setting, compares it to the current one, and only calls setrlimit() if
one of the values in the new setting is larger than the older one. As such
it will continue to emit warnings and errors in case of failure to raise
the limit but will never shrink it.
This patch is only preliminary to another one, but will have to be
backported where relevant (likely only 2.6).
(cherry picked from commit 922a907926d1cb02a8a10c7cdb9917755c934c84)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Building h1.c with gcc-4.7 -Os produces the following warning:
src/h1.c: In function 'h1_headers_to_hdr_list':
src/h1.c:1101:36: warning: 'ptr' may be used uninitialized in this function [-Wmaybe-uninitialized]
In fact ptr may be taken from sl.rq.u.ptr which is only initialized after
passing through the relevant states, but gcc doesn't know which states
are visited. Adding an ALREADY_CHECKED() statement there is sufficient to
shut it up and doesn't affect the emitted code.
This may be backported to stable versions to make sure that builds on older
distros and systems is clean.
(cherry picked from commit 55d2e8577e5ae0e7ac0cdbf5201b4836b5d7ad3c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
In hlua_lua2arg_check(), we allow for the first argument to not be
provided, if it has a type we know, this is true for frontend, backend,
and stick table. However, the stick table code was changed. It used
to be deduced from the proxy, but it is now directly provided in struct
args. So setting the proxy there no longer work, and we have to
explicitely set the stick table.
Not doing so will lead the code do use the proxy pointer as a stick
table pointer, which will likely cause crashes.
This should be backported up to 2.0.
(cherry picked from commit 14f62688839dc7245ca87e040f14fbd2147698e6)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
In hlua_lua2arg_check(), on failure, before calling free_argp(), make
sure to always mark the failed argument as ARGT_STOP. We only want to
free argument prior to that point, because we did not allocate the
strings after this one, and so we don't want to free them.
This should be backported up to 2.2.
(cherry picked from commit ca43161a8da278ec0948511f595827daf29a071e)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
It is possible to receive a STOP_SENDING frame for a locally closed
stream. This was not properly managed as this would result in a BUG_ON()
crash from qcs_idle_open() call under qcc_recv_stop_sending().
Now, STOP_SENDING frames are ignored when received on streams already
locally closed. This has two consequences depending on the reason of
closure :
* if a RESET_STREAM was already emitted and closed the stream, this
patch prevents to emit a new RESET_STREAM. This behavior is thus
better.
* if stream was closed due to all data transmitted, no RESET_STREAM will
be built. This is contrary to the RFC 9000 which advice to transmit
it, even on "Data Sent" state. However, this is not mandatory so the
new behavior is acceptable, even if it could be improved.
This crash has been detected on haproxy.org. This can be artifically
reproduced by adding the following snippet at the end of qc_send_mux()
when doing a request with a small payload response :
qcc_recv_stop_sending(qc->qcc, 0, 0);
This must be backported up to 2.6.
(cherry picked from commit d7755375a51726e3d13c4f891ca8ab8cc1ba9a4d)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
xprt_quic module was too large and did not reflect the true architecture
by contrast to the other protocols in haproxy.
Extract code related to XPRT layer and keep it under xprt_quic module.
This code should only contains a simple API to communicate between QUIC
lower layer and connection/MUX.
The vast majority of the code has been moved into a new module named
quic_conn. This module is responsible to the implementation of QUIC
lower layer. Conceptually, it overlaps with TCP kernel implementation
when comparing QUIC and HTTP1/2 stacks of haproxy.
This should be backported up to 2.6.
(cherry picked from commit 92fa63f73596bf7e567b7bbd600dd8621a1b49ad)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
There was some identical code between xprt_quic and quic_enc modules.
This concerns helper on QUIC varint type. Keep only the version in
quic_enc file : this should help to reduce dependency on xprt_quic
module.
Note that quic_max_int_by_size() has been removed and is replaced by the
identical quic_max_int().
This should be backported up to 2.6.
(cherry picked from commit a2639383ece04c2fee3bbdda54dab66a640f6aa1)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Removed hexdump unusued prototype from quic_tls.c.
This should be backported up to 2.6.
(cherry picked from commit ac9bf016bfcb5608b4d29d029f20a45709ac0a2d)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Clean up quic sources by adjusting headers list included depending
on the actual dependency of each source file.
On some occasion, xprt_quic.h was removed from included list. This is
useful to help reducing the dependency on this single file and cleaning
up QUIC haproxy architecture.
This should be backported up to 2.6.
(cherry picked from commit 5c25dc5bfd5d253925f954aab072a2bf1fd1d6e2)
[cf: Include <haproxy/global.h> from cfgparse-quic.c instead of only
<haproxy/global-t.h">. On 2.7, it is shipped with "tools.h" (tools.h >
cli.h > global.h). But not on the 2.6]
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Two prototypes in quic_tls module were not identical to the actual
function definition.
* quic_tls_decrypt2() : the second argument const attribute is not
present, to be able to use it with EVP_CIPHER_CTX_ctlr(). As a
consequence of this change, token field of quic_rx_packet is now
declared as non-const.
* quic_tls_generate_retry_integrity_tag() : the second argument type
differ between the two. Adjust this by fixing it to as unsigned char
to match EVP_EncryptUpdate() SSL function.
This situation did not seem to have any visible effect. However, this is
clearly an undefined behavior and should be treated as a bug.
This should be backported up to 2.6.
(cherry picked from commit f3c40f83fbfc6fb60ba5608ccfbd00fb51e6f9b3)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Some variables related to QUIC TLS were defined in a header file : their
definitions are now moved properly in the implementation file, with only
declarations in the header.
This should be backported up to 2.6.
(cherry picked from commit a19bb6f0b2af1971775e4a88edfaed85d42162c6)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
ull is a typedef to unsigned long long. It is only defined in
xprt_quic-t.h. Its usage should be limited over time to reduce xprt_quic
dependency over the whole code. It can be replaced by ullong typedef
from compat.h.
For the moment, ull references have been replaced in qmux_trace module.
They were only used for printf format and has been replaced by the true
variable type.
This change is useful to reduce dependencies on xprt_quic in other
files.
This should be backported up to 2.6.
(cherry picked from commit d6922d5471e0486958b8f979246d1ac3b37b222d)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
The username is required in the Start-up message. Thus, since the 2.2, when
this health-check was refactored, the user parameter is mandatory. On prior
versions, when no username is provided, no pgsql check is performed but only
a basic tcpcheck.
This patch should be backported as far as 2.2.
(cherry picked from commit 59307b3e4e1fbdbe07dcbe08781c81e6312f0c23)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
This patch adds support to the following authentication methods:
- AUTH_REQ_GSS (7)
- AUTH_REQ_SSPI (9)
- AUTH_REQ_SASL (10)
Note that since AUTH_REQ_SASL allows multiple authentication mechanisms
such as SCRAM-SHA-256 or SCRAM-SHA-256-PLUS, the auth payload length may
vary since the method is sent in plaintext. In order to allow this, the
regex now matches any payload length.
This partially fixes Github issue #1508 since user authentication is
still broken but should restore pre-2.2 behavior.
This should be backported up to 2.2.
Signed-off-by: Fatih Acar <facar@scaleway.com>
(cherry picked from commit 0d6fb7a3eb0a9754348ec15be14a017a1c84df0f)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
In github issue #1878, Bart Butler reported observing turn-around states
(1 second pause) after connection retries going to different servers,
while this ought not happen.
In fact it does happen because back_handle_st_cer() enforces the TAR
state for any algo that's not round-robin. This means that even leastconn
has it, as well as hashes after the number of servers changed.
Prior to doing that, the call to stream_choose_redispatch() has already
had a chance to perform the correct choice and to check the algo and
the number of retries left. So instead we should just let that function
deal with the algo when needed (and focus on deterministic ones), and
let the former just obey. Bart confirmed that the fixed version works
as expected (no more delays during retries).
This may be backported to older releases, though it doesn't seem very
important. At least Bart would like to have it in 2.4 so let's go there
for now after it has cooked a few weeks in 2.6.
(cherry picked from commit 406efb96d135efe1d5a85bf58c589f7b6dbd8c70)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Idle connections do not work on 32-bit machines due to an alignment issue
causing the connection nodes to be indexed with their lower 32-bits set to
zero and the higher 32 ones containing the 32 lower bitss of the hash. The
cause is the use of ebmb_node with an aligned data, as on this platform
ebmb_node is only 32-bit aligned, leaving a hole before the following hash
which is a uint64_t:
$ pahole -C conn_hash_node ./haproxy
struct conn_hash_node {
struct ebmb_node node; /* 0 20 */
/* XXX 4 bytes hole, try to pack */
int64_t hash; /* 24 8 */
struct connection * conn; /* 32 4 */
/* size: 40, cachelines: 1, members: 3 */
/* sum members: 32, holes: 1, sum holes: 4 */
/* padding: 4 */
/* last cacheline: 40 bytes */
};
Instead, eb64 nodes should be used when it comes to simply storing a
64-bit key, and that is what this patch does.
For backports, a variant consisting in simply marking the "hash" member
with a "packed" attribute on the struct also does the job (tested), and
might be preferable if the fix is difficult to adapt. Only 2.6 and 2.5
are affected by this.
(cherry picked from commit 852234848241f61a976f8856123a34a3c19275ba)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
The httpclient does support DNS resolution since 2.6.
Must be backported to 2.6.
(cherry picked from commit 9ae05bb1e082577858e9f51e04f8ef0c7cb25383)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Calling the function with an offset when "offset + len" was superior or equal
to the targeted blk length caused 'v' value to be improperly set.
And because 'v' is directly provided to htx_replace_blk_value(), blk consistency was compromised.
(It seems that blk was overrunning in htx_replace_blk_value() due to
this and header data was overwritten in this case).
This patch adds the missing checks to make the function behave as
expected when offset is set and offset+len is greater or equals to the targeted blk length.
Some comments were added to the function as well.
It may be backported to 2.6 and 2.5
(cherry picked from commit bcbcf98e0c0149f91365f1f2d207be018124f6f2)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
hlua_http_msg_insert_data() function is called upon
HTTPMessage.insert() method from lua script.
This function did not work properly for multiple reasons:
- An incorrect argument check was performed and prevented the user
from providing optional offset argument.
- Input and output variables were inverted
and offset was not handled properly. The same bug
was also fixed in hlua_http_msg_del_data(), see:
'BUG/MINOR: hlua: fixing hlua_http_msg_del_data behavior'
The function now behaves as described in the documentation.
This could be backported to 2.6 and 2.5.
(cherry picked from commit 7fdba0ae544cb1b14b7d3864b06f38c752505094)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
GH issue #1885 reported that HTTPMessage.remove() did not
work as expected.
It turns out that underlying hlua_http_msg_del_data() function
was not working properly due to input / output inversion as well
as incorrect user offset handling.
This patch fixes it so that the behavior is the one described in
the documentation.
This could be backported to 2.6 and 2.5.
(cherry picked from commit d7c71b03d83144913a33a09080c3738b27395af8)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
To avoid any UAF when a resolution is released, a mechanism was added to
abort a resolution and delayed the released at the end of the current
execution path. This mechanism depends on an hard assumption: Any reference
on an aborted resolution must be removed. So, when a resolution is aborted,
it is removed from the resolver lists and inserted into a death row list.
However, a resolution may still be referenced in the query_ids tree. It is
the tree containing all resolutions with a pending request. Because aborted
resolutions are released outside the resolvers lock, it is possible to
release a resolution on a side while a query ansswer is received and
processed on another one. Thus, it is still possible to have a UAF because
of this bug.
To fix the issue, when a resolution is aborted, it is removed from any list,
but it is also removed from the query_ids tree.
This patch should solve the issue #1862 and may be related to #1875. It must
be backported as far as 2.2.
(cherry picked from commit eaabf060312f6aad1c0c195ad33e5ea612acc47a)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
If stream_new() fails after the frontend SC is attached, the underlying SE
descriptor is not properly reset. Among other things, SE_FL_ORPHAN flag is
not set again. Because of this error, a BUG_ON() is triggered when the mux
stream on the frontend side is destroyed.
Thus, now, when stream_new() fails, SE_FL_ORPHAN flag is set on the SE
descriptor and its stream-connector is set to NULL.
This patch should solve the issue #1880. It must be backported to 2.6.
(cherry picked from commit 3ab72c66a01ca81aa93cf1f0bd29430db8271792)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
The frontend SC is attached before the backend one is allocated. Thus an
allocation error on backend SC must be handled before an error on the
frontend SC.
This patch must be backported to 2.6.
(cherry picked from commit 4cfc038cb19996f5d2fe60284fdb556503a5f9ef)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Because memprintf return an error to the caller and not on screen.
the function which perform display of message on the right output
is in charge of adding \n if it is necessary.
This patch may be backported.
(cherry picked from commit 70e38e91b41c3446cd6d7993dd71fe6100996fa3)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
The s1 server is acting like a SMTP server. But it sends two CRLF at the end of
each line, while only one CRLF must be returned. It only works becaue both CRLF
are received at the same time.
(cherry picked from commit 330af2d7ed2d8d72800fc7761253ff6965681742)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Released version 2.6.6 with the following main changes :
- MEDIUM: peers: limit the number of updates sent at once
- MINOR: Revert part of clarifying samples support per os commit
- BUILD: makefile: enable crypt(3) for NetBSD
- BUG/MINOR: quic: Retransmitted frames marked as acknowledged
- BUG/MINOR: quic: Possible crash with "tls-ticket-keys" on QUIC bind lines
- BUG/MINOR: h1: Support headers case adjustment for TCP proxies
- BUG/MINOR: quic: Possible crash when verifying certificates
- BUILD: quic: add some ifdef around the SSL_ERROR_* for libressl
- BUILD: ssl: fix ssl_sock_switchtx_cbk when no client_hello_cb
- BUILD: quic: temporarly ignore chacha20_poly1305 for libressl
- BUILD: quic: enable early data only with >= openssl 1.1.1
- BUILD: ssl: fix the ifdef mess in ssl_sock_initial_ctx
- BUILD: quic: fix the #ifdef in ssl_quic_initial_ctx()
- MINOR: quic: add QUIC support when no client_hello_cb
- MINOR: quic: Add traces about sent or resent TX frames
- MINOR: quic: No TRACE_LEAVE() in retrieve_qc_conn_from_cid()
- BUG/MINOR: quic: Wrong connection ID to thread ID association
- BUG/MINOR: task: always reset a new tasklet's call date
- BUG/MINOR: task: make task_instant_wakeup() work on a task not a tasklet
- MINOR: task: permanently enable latency measurement on tasklets
- CLEANUP: task: rename ->call_date to ->wake_date
- BUG/MINOR: task: Fix detection of tasks profiling in tasklet_wakeup_after()
- BUG/MINOR: sched: properly account for the CPU time of dying tasks
- MINOR: sched: store the current profile entry in the thread context
- BUG/MINOR: stream/sched: take into account CPU profiling for the last call
- BUG/MINOR: signals/poller: set the poller timeout to 0 when there are signals
- BUG/MINOR: quic: Speed up the handshake completion only one time
- BUG/MINOR: quic: Trace fix about packet number space information.
- BUG/MINOR: h3: Crash when h3 trace verbosity is "minimal"
- MINOR: h3: Add the quic_conn object to h3 traces
- MINOR: h3: Missing connection argument for a TRACE_LEAVE() argument
- MINOR: h3: Send the h3 settings with others streams (requests)
- BUG/MINOR: signals/poller: ensure wakeup from signals
- CI: cirrus-ci: bump FreeBSD image to 13-1
- DEV: flags: fix usage message to reflect available options
- DEV: flags: add missing CO_FL_FDLESS connection flag
- BUG/MEDIUM: proxy: ensure pause_proxy() and resume_proxy() own PROXY_LOCK
- MINOR: listener: small API change
- MINOR: proxy/listener: support for additional PAUSED state
- BUG/MINOR: stats: fixing stat shows disabled frontend status as 'OPEN'
- CLEANUP: pollers: remove dead code in the polling loop
- BUG/MINOR: mux-h1: Increment open_streams counter when H1 stream is created
- REGTESTS: healthcheckmail: Relax matching on the healthcheck log message
- CLEANUP: listener: function comment typo in stop_listener()
- BUG/MINOR: listener: null pointer dereference suspected by coverity
- REGTESTS: log: test the log-forward feature
- BUG/MEDIUM: sink: bad init sequence on tcp sink from a ring.
- REGTESTS: ssl/log: test the log-forward with SSL
- DOC: fix TOC in starter guide for subsection 3.3.8. Statistics
- MEDIUM: quic: separate path for rx and tx with set_encryption_secrets
- BUG/MEDIUM: mux-quic: fix crash on early app-ops release
- CLEANUP: mux-quic: remove stconn usage in h3/hq
- BUG/MINOR: mux-quic: do not remotely close stream too early
- BUG/MEDIUM: server: segv when adding server with hostname from CLI
- CLEANUP: quic,ssl: fix tiny typos in C comments
- BUG/MEDIUM: captures: free() an error capture out of the proxy lock
- BUILD: fd: fix a build warning on the DWCAS
- SCRIPTS: announce-release: update some URLs to https
- BUG/MEDIUM: mux-quic: fix nb_hreq decrement
- BUG/MINOR: mux-quic: do not keep detached qcs with empty Tx buffers
- REORG: mux-quic: extract traces in a dedicated source file
- REORG: mux-quic: export HTTP related function in a dedicated file
- MINOR: mux-quic: refactor snd_buf
- BUG/MEDIUM: mux-quic: properly trim HTX buffer on snd_buf reset
- REGTESTS: ssl: adopt tests to OpenSSL-3.0.N
- REGTESTS: ssl: adopt tests to OpenSSL-3.0.N
- REGTESTS: ssl: fix grep invocation to use extended regex in ssl_generate_certificate.vtc
- BUG/MINOR: log: improper behavior when escaping log data
Patrick Hemmer reported an improper log behavior when using
log-format to escape log data (+E option):
Some bytes were truncated from the output:
- escape_string() function now takes an extra parameter that
allow the caller to specify input string stop pointer in
case the input string is not guaranteed to be zero-terminated.
- Minors checks were added into lf_text_len() to make sure dst
string will not overflow.
- lf_text_len() now makes proper use of escape_string() function.
This should be backported as far as 1.8.
(cherry picked from commit c5bff8e550cf49b0cb3a7abb998b2c915323eca9)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
in 2f2a2884b7464ccb56469cb94d8a1ae4015a8cb6 grep should have use regex flag -E, but flag
was lost by mistake
(cherry picked from commit b6189bc268255b799a77fdffcaaa7b221ca2d7a9)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
on Ubuntu-22.04 openssl-3.0.5 is shipped which has changed ec curve
description to "Server Temp Key: ECDH, secp384r1, 384 bits"
(cherry picked from commit 2f2a2884b7464ccb56469cb94d8a1ae4015a8cb6)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
on Ubuntu-22.04 openssl-3.0.5 is shipped which has changed ec curve
description to "Server Temp Key: ECDH, prime256v1, 256 bits"
(cherry picked from commit 0865160b93b1ac8326ac0e5b57be24504070c2c1)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
MUX QUIC snd_buf operation whill return early if a qcs instance is
resetted. In this case, HTX is left untouched and the callback returns
the whole bufer size. This lead to an undefined behavior as the stream
layer is notified about a transfer but does not see its HTX buffer
emptied. In the end, the transfer may stall which will lead to a leak on
session.
To fix this, HTX buffer is now resetted when snd_buf is short-circuited.
This should fix the issue as now the stream layer can continue the
transfer until its completion.
This patch has already been tested by Tristan and is reported to solve
the github issue #1801.
This should be backported up to 2.6.
(cherry picked from commit 0ed617ac2ff377ce60bd9c8fd97fd9da32d43971)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
