[PATCH] BUG/MINOR: ssl: fix crt-list neg filter for openssl < 1.1.1
Hi, Very difficult to trigger the bug, except with spécific test configuration like: crt-list: cert.pem !www.dom.tld cert.pem *.dom.tld If you can consider the patch. Thank's Manu 0001-BUG-MINOR-ssl-fix-crt-list-neg-filter-for-openssl-1..patch Description: Binary data
[PATCH v3] MINOR: stick-table: allow sc-set-gpt0 to set value from an expression
[sorry for mis-threading; hoping I got the git send-mail --in-reply-to right]
Hello Willy!
Actually, reading through your original and last comments, I realize I must
have misunderstood the sample_expr() part and got carried away.
Unless I'm mistaken, we can use the existing sample_fetch_as_type() function
directly (without any further addition to sample.c). Or am I missing something ?
This leaves the switch(rule->from) <-> smpt_opt_dir stuff. Since there is
nothing about act_rule in sample.c so I felt it has no place there.
Wouldn't an extra function call just to deal with this switch() be overkill ?
Let me know if you still think this ought to go in a separate function
(like if anticipating set_gpt1 :-) ).
Best,
Cédric
[patch]
Allow the sc-set-gpt0 action to set GPT0 to a value dynamically evaluated from
its argument (in addition to the existing static alternative).
---
doc/configuration.txt | 44 +---
include/types/action.h | 1 +
src/stick_table.c | 57 +++---
3 files changed, 79 insertions(+), 23 deletions(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 8dedbfc48..bea62bd98 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -4465,11 +4465,13 @@ http-request sc-inc-gpc1() [ { if | unless }
]
counter designated by . If an error occurs, this action silently fails
and the actions evaluation continues.
-http-request sc-set-gpt0() [ { if | unless } ]
+http-request sc-set-gpt0() { | }
+ [ { if | unless } ]
- This action sets the GPT0 tag according to the sticky counter designated by
- and the value of . The expected result is a boolean. If an error
- occurs, this action silently fails and the actions evaluation continues.
+ This action sets the 32-bit unsigned GPT0 tag according to the sticky counter
+ designated by and the value of /. The expected result is a
+ boolean. If an error occurs, this action silently fails and the actions
+ evaluation continues.
http-request set-dst [ { if | unless } ]
@@ -4974,11 +4976,13 @@ http-response sc-inc-gpc1() [ { if | unless }
]
counter designated by . If an error occurs, this action silently fails
and the actions evaluation continues.
-http-response sc-set-gpt0() [ { if | unless } ]
+http-response sc-set-gpt0() { | }
+ [ { if | unless } ]
- This action sets the GPT0 tag according to the sticky counter designated by
- and the value of . The expected result is a boolean. If an error
- occurs, this action silently fails and the actions evaluation continues.
+ This action sets the 32-bit unsigned GPT0 tag according to the sticky counter
+ designated by and the value of /. The expected result is a
+ boolean. If an error occurs, this action silently fails and the actions
+ evaluation continues.
http-response send-spoe-group [ { if | unless } ]
@@ -9394,11 +9398,11 @@ tcp-request connection [{if | unless}
]
counter designated by . If an error occurs, this action silently
fails and the actions evaluation continues.
-- sc-set-gpt0() :
-This action sets the GPT0 tag according to the sticky counter
designated
-by and the value of . The expected result is a boolean. If
-an error occurs, this action silently fails and the actions evaluation
-continues.
+- sc-set-gpt0() { | }:
+This action sets the 32-bit unsigned GPT0 tag according to the sticky
+counter designated by and the value of /. The
+expected result is a boolean. If an error occurs, this action silently
+fails and the actions evaluation continues.
- set-src :
Is used to set the source IP address to the value of specified
@@ -9556,7 +9560,7 @@ tcp-request content [{if | unless} ]
- { track-sc0 | track-sc1 | track-sc2 } [table ]
- sc-inc-gpc0()
- sc-inc-gpc1()
-- sc-set-gpt0()
+- sc-set-gpt0() { | }
- set-dst
- set-dst-port
- set-var()
@@ -9820,11 +9824,11 @@ tcp-response content [{if | unless}
]
counter designated by . If an error occurs, this action fails
silently and the actions evaluation continues.
-- sc-set-gpt0() :
-This action sets the GPT0 tag according to the sticky counter
designated
-by and the value of . The expected result is a boolean. If
-an error occurs, this action silently fails and the actions evaluation
-continues.
+- sc-set-gpt0() { | }
+This action sets the 32-bit unsigned GPT0 tag according to the sticky
+counter designated by and the value of /. The
+expected result is a boolean. If an error occurs, this action silently
+fails and the actions evaluation continues.
- "silent-drop" :
This stops the evaluation of the rules and makes the client-facing
@@ -9945,7 +9949,7 @@ tcp-request
[PATCH] BUG/MINOR: ssl: ssl_pkey_info_index ex_data can store a dereferenced pointer
Hi, If you can consider the patch (related to CLI cert update) Thank's Manu 0001-BUG-MINOR-ssl-ssl_pkey_info_index-ex_data-can-store-.patch Description: Binary data
Re: Delegated Credentials for TLS
Hello, On Wed, Nov 6, 2019 at 3:50 PM Dana Dukes wrote: > > Greetings, > > I was wondering if any plans for Delegated Credentials to be supported in > HAProxy. > > https://thehackernews.com/2019/11/delegated-credentials-for-tls.html I'd say it's a little early for that. Without an actual ratified standard and an implementation in a stable openssl branch, there is not much to think about at this point. Lukas
Delegated Credentials for TLS
Greetings,I was wondering if any plans for Delegated Credentials to be supported in HAProxy. https://thehackernews.com/2019/11/delegated-credentials-for-tls.html
Re: Truncated response on 2.0.8
Le 31/10/2019 à 11:01, Ing. Andrea Vettori a écrit : Sorry to bother you with all these stuff. But for now, I don't know where to start my investigation. Sure I’ll do as soon as possibile and thank you very much for your continued support. Hi, Sorry for the delay and thanks for the captures you sent me. In them, I noticed 2 things that explain the truncated responses : * Firstly, when you send your request through HAProxy, your server send a frame GOAWAY with the error code ERR_ENHANCE_YOUR_CALM(11) in the middle of the response transfer. Because, once the request is sent, HAProxy only send frames WINDOW_UPDATE, I guess your server has some "security" mechanism about those frames. Or it is a bug. I don't know. The last stream ID indicated in the frame GOAWAY is the one of your request. So, the response transfer should normally be continued. In itself, it is not really a problem. And the transfer is effectively still in progress because in the captures, we can see a frame DATA following the GOAWAY. But after that, your server aborts the transfer by closing the connection with a TCP reset, probably because it receives some other frames WINDOW_UPDATE from HAProxy. * Secondly, the server abort is not properly handled on the client side by the mux h2. It is definitely a bug. We should normally send a RST_STREAM to abort the request. Instead, we mark the end of the response with an empty frame DATA with the flag END_STREAM set. Because there is no content-length specified on the response, the client has no way to know that the response was truncated. So, this bug must be addressed. We're still discussing with Willy to know how to do it properly. But, in the end, it requires some fundamental changes on the way aborts are handle in HAProxy. We are rather reluctant to do a quick patch. Once said, the problem remains on your server side, because it aborts the response transfer. I noticed the last WINDOW_UPDATE before the GOAWAY has a length of 1. This may be related. -- Christopher Faulet
Re: [PATCH] bugfix to make do-resolve to use DNS cache
Hi Willy, Jarno,
Sorry, I did forgot those 2 printf that were here for debugging purpose
only.
I can resend the patch tonight.
Baptiste
On Wed, Nov 6, 2019 at 7:43 AM Willy Tarreau wrote:
> Hi Baptiste,
>
> thanks for the fix, but before taking it, are you really sure it's
> the version you wanted to send ? There are a couple of debugging
> printf() left so I could remove them by hand but maybe you intended
> to send a different patch, thus I'd rather let you double-check.
>
> thanks,
> Willy
>
> On Tue, Nov 05, 2019 at 10:04:30AM +0100, Baptiste wrote:
> > diff --git a/src/action.c b/src/action.c
> > index 7684202..36eedc8 100644
> > --- a/src/action.c
> > +++ b/src/action.c
> > @@ -73,6 +73,7 @@ int check_trk_action(struct act_rule *rule, struct
> proxy *px, char **err)
> > int act_resolution_cb(struct dns_requester *requester, struct
> dns_nameserver *nameserver)
> > {
> > struct stream *stream;
> > +printf("%s %d\n", __FUNCTION__, __LINE__);
> >
> > if (requester->resolution == NULL)
> > return 0;
> > @@ -89,6 +90,7 @@ int act_resolution_cb(struct dns_requester *requester,
> struct dns_nameserver *na
> > int act_resolution_error_cb(struct dns_requester *requester, int
> error_code)
> > {
> > struct stream *stream;
> > +printf("%s %d\n", __FUNCTION__, __LINE__);
> >
> > if (requester->resolution == NULL)
> > return 0;
> > diff --git a/src/dns.c b/src/dns.c
> > index 15d40a1..d5bf449 100644
> > --- a/src/dns.c
> > +++ b/src/dns.c
> > @@ -363,8 +363,9 @@ void dns_trigger_resolution(struct dns_requester
> *req)
> >* valid */
> > exp = tick_add(res->last_resolution, resolvers->hold.valid);
> > if (resolvers->t && (res->status != RSLV_STATUS_VALID ||
> > - !tick_isset(res->last_resolution) || tick_is_expired(exp,
> now_ms)))
> > + !tick_isset(res->last_resolution) || tick_is_expired(exp,
> now_ms))) {
> > task_wakeup(resolvers->t, TASK_WOKEN_OTHER);
> > + }
> > }
> >
> >
> > @@ -2150,8 +2151,13 @@ enum act_return dns_action_do_resolve(struct
> act_rule *rule, struct proxy *px,
> > struct dns_resolution *resolution;
> > struct sample *smp;
> > char *fqdn;
> > + struct dns_requester *req;
> > + struct dns_resolvers *resolvers;
> > + struct dns_resolution *res;
> > + int exp;
> >
> > /* we have a response to our DNS resolution */
> > + use_cache:
> > if (s->dns_ctx.dns_requester &&
> s->dns_ctx.dns_requester->resolution != NULL) {
> > resolution = s->dns_ctx.dns_requester->resolution;
> > if (resolution->step == RSLV_STEP_RUNNING) {
> > @@ -2211,6 +2217,22 @@ enum act_return dns_action_do_resolve(struct
> act_rule *rule, struct proxy *px,
> >
> > s->dns_ctx.parent = rule;
> > dns_link_resolution(s, OBJ_TYPE_STREAM, 0);
> > +
> > + /* Check if there is a fresh enough response in the cache of our
> associated resolution */
> > + req = s->dns_ctx.dns_requester;
> > + if (!req || !req->resolution) {
> > + dns_trigger_resolution(s->dns_ctx.dns_requester);
> > + return ACT_RET_YIELD;
> > + }
> > + res = req->resolution;
> > + resolvers = res->resolvers;
> > +
> > + exp = tick_add(res->last_resolution, resolvers->hold.valid);
> > + if (resolvers->t && res->status == RSLV_STATUS_VALID &&
> tick_isset(res->last_resolution)
> > +&& !tick_is_expired(exp, now_ms)) {
> > + goto use_cache;
> > + }
> > +
> > dns_trigger_resolution(s->dns_ctx.dns_requester);
> > return ACT_RET_YIELD;
> > }
> > --
> > 2.7.4
> >
>
>
Re: [PATCH v2] MINOR: stick-table: allow sc-set-gpt0 to set value from an expression
Hi Cédric, On Mon, Nov 04, 2019 at 11:00:06AM +0100, Cédric Dufour wrote: > [Sorry for multiple posting. I'm having trouble with sending this > patch via GMail *SMTP*; trying the WUI...] no worries. > Thanks Willy for your feedback. > > I'm not sure whether I should further split stktable_fetch_expr() into > some new sample_...() in sample.c or if there is some other *.c file where > a generic function, including the required act_rule, would make sense. At the moment I must confess I have no authoritative opinion, for not having studied that area in a while. However I suspect that your new function stktable_fetch_expr() is in fact not related to stick tables at all and should entirely be in sample.c with a sample_ name. I think you got confused by the fact that this action works both on a sample and an expression, but the part you're dealing with is entirely a sample expression. > Also, I'm not HAProxy-savvy enough to know whether this proposal is > multi-thread safe (is it ?). Yes it is. All our datapath is thread-safe for now because execution of all processing happens on the same thread from end to end. However if you would access central resources like server states, stick-table contents, queues or such stuff, then you'd have to take additional precautions. I think I'll soon start to write some doc on this after the conference. Otherwise your patch looks good and reasonably non-intrusive so that we can get it into 2.1 in time. I would appreciate it if you could split it so that the new generic function is in its own patch and that a second patch only implements support for it from sc-set-gpt0(). This would simplify future backports if needed at any point in time, typically if your generic function becomes required for something else in the future. Thanks! Willy
Re: arm64 builds?
Hi Ionel, On Mon, Nov 04, 2019 at 02:10:56PM +0100, GARDAIS Ionel wrote: > FWIW, when I build for armhf (RaspberryPi 3b with Raspbian buster), I have to > add -latomic to the LD_FLAGS. It's not the case for me but I had to add it for another one, I think it was for the mips running in my build farm's controller. It's easy to detect usually, if the linking fails with atomic operations you know you need it. Willy
Re: [PATCH] MINOR: doc: http-reuse connection pool fix
On Wed, Nov 06, 2019 at 11:50:25AM +0100, Lukas Tribus wrote: > Since 1.9 we actually do use a connection pool, configurable with > pool-max-conn. > > Update the documentation in this regard. > > Must be backported to 1.9. Nice catch, thanks Lukas, now applied. Willy
[PATCH] MINOR: doc: http-reuse connection pool fix
Since 1.9 we actually do use a connection pool, configurable with
pool-max-conn.
Update the documentation in this regard.
Must be backported to 1.9.
---
doc/configuration.txt | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index beb2726..a4841fc 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -5206,9 +5206,7 @@ http-reuse { never | safe | aggressive | always }
- connections with certain bogus authentication schemes (relying on the
connection) like NTLM are detected, marked private and are never shared;
- No connection pool is involved, once a session dies, the last idle connection
- it was attached to is deleted at the same time. This ensures that connections
- may not last after all sessions are closed.
+ A connection pool is involved and configurable with "pool-max-conn".
Note: connection reuse improves the accuracy of the "server maxconn" setting,
because almost no new connection will be established while idle connections
--
2.7.4
RE: Product Info
Okay Lucas and all. Thanks for all your help and have a great day ahead. Regards, Anurag -Original Message- From: Lucas Rolff Sent: Wednesday, November 6, 2019 2:36 PM To: APCoE Product Notifications ; w...@1wt.eu Cc: xro...@gmail.com; haproxy@formilux.org; Na, Anurag Subject: Re: Product Info I think the point Willy tried to make is that it should be handled the same way regardless of being a security patch or not. All fixes are important - so see them as "security" fixes for bugs if you like. On 06/11/2019, 10.04, "apcoeproductnotificati...@wellsfargo.com" wrote: Hi Willy, Thanks for the info but honestly I am not focusing only on security fix, I need confirmation whether 2.0.8 is security patch or discretionary patch so that I can work on it accordingly on the basis of patch type. Regards, Anurag -Original Message- From: Willy Tarreau Sent: Wednesday, November 6, 2019 2:15 PM To: APCoE Product Notifications Cc: xro...@gmail.com; haproxy@formilux.org; Na, Anurag Subject: Re: Product Info On Wed, Nov 06, 2019 at 08:09:55AM +, apcoeproductnotificati...@wellsfargo.com wrote: > Hi Rob/Thomas, > Good day!! > > Thanks for the update, so as per the link the current patch is 2.0.8 > released on 23-10-2019, request you to please confirm whether this > patch is also a security patch and fixing any vulnerability (please > provide CVE if available) or not as it has one major bug fix in the release notes. Well, it was marked security since considered as such by the reporter eventhough it requires you to use a vulnerable server and to purposely write a bogus configuration, so my personal opinion on it is that it's very minor compared to all the issues we fix on a daily basis. In addition, please note that ALL FIXES ARE IMPORTANT and that if you're trying to only pick fixes explicitly marked as security, you'll end up with the most bogus load balancer on earth, and you'd rather not do this at all if you care for your site's availability. Focusing on CVEs only is part of what Linus Torvalds calls the "security circus" and I fully agree with him on that, considering how harmful most bugs can be for production and which are dropped by people focusing on CVE only and who instead pick irrelevant stuff because these have a "security" sticker. Also please have a look at this presentation by GregKH explaining the ridiculous situation we've reached with CVE nowadays: https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/ In short if you're wondering what patch to pick, you WILL eventually cause some disaster on your production that only YOU will be responsible for, by having deliberately rejected important fixes. You'd rather rely on up-to-date releases, either from sources if you build yourself, or from distro maintainers if you prefer to use pre-built packages. The project maintainers devote a lot of time maintaining stable branches containing only fixes precisely so that nobody has to duplicate this boring and dangerous job. Note that if you fear regressions, it's normal. Nobody likes to face them. In this case, just wait one week or even one month for others to deploy a new version before you do so, and you'll know if you're taking any risk. Everyone does this depending on the criticity. What is certain is that by not updating you're taking the risk to hit any of the hundreds of bugs that are known and fixed upstream. Willy
Re: stats http counter issue
On Wed, Nov 06, 2019 at 11:03:47AM +0100, Jean Wasilewski wrote: > Removing nbproc and nbthread did resolve the issue. Ah I like to read this! When less settings work better, it's always pleasant and confirms that all this dev was time well invested! Cheers, Wlily
Re: stats http counter issue
Hi Willy, On 11-06 07:56 am (Wed), Willy Tarreau wrote: > Hi Jean, > > On Tue, Nov 05, 2019 at 04:33:00PM +0100, Jean Wasilewski wrote: > > Hi, > > > > While using the stats socket with the official HAProxy exporter, I > > noticed that some metrics seem erronous. While querying for a specific > > frontend, the admin socket reported two differents metrics for the same > > frontend. > > > > I made this small onliner two retrieve values (with here an example on > > 2XX calls on our frontend `console-online`): > > > > ``` > > $ while true; do echo "show stat" | socat - /run/haproxy/admin.sock |grep \ > > -E '\#|FRONT' |grep -E '\#|console' |cut -d, -f41 |xargs -L2 echo; sleep \ > > 1; done > > hrsp_2xx 2141807 > > hrsp_2xx 136536 > > hrsp_2xx 2141819 > > hrsp_2xx 2141828 > > hrsp_2xx 136536 > > hrsp_2xx 2141841 > > hrsp_2xx 2141846 > > hrsp_2xx 136537 > > hrsp_2xx 2141854 > > hrsp_2xx 2141856 > > hrsp_2xx 2141863 > > hrsp_2xx 136537 > > ``` > > > > Is this a bug or a misconfiguration? > > It sounds like you're working in multi-process mode (nbproc > 1). If Indeed, nproc was set to 2. > so, this is the expected behavior since stats are per process. This > was one of the drivers for the porting to threads. If for any reason > you really want to stick to nbproc, then I'd recommend you to use one > stats socket per process (use the "process" directive on each line) > and to query both of them individually. But frankly this is painful as > it may return conflicting server states during some transitions because > the checks are per-process as well. > > You can replace "nbproc 2" with "nbthread 2" in your config, watch for > warnings in case you'd already have a few explicit "process" entries, > or even remove nbproc and nbthread to let haproxy start one thread per > available core. Removing nbproc and nbthread did resolve the issue. > > Hoping this helps, > Willy Thank you very much! Jean signature.asc Description: PGP signature
Re: Product Info
On Wed, Nov 06, 2019 at 09:03:50AM +, apcoeproductnotificati...@wellsfargo.com wrote: > Hi Willy, > > Thanks for the info but honestly I am not focusing only on security fix, That's already great to hear, because you know it's not the first time I hear this question! > I need confirmation whether 2.0.8 is security patch or discretionary > patch so that I can work on it accordingly on the basis of patch type. 2.0.8 is a regular maintenance release which fixes a number of bugs, some of which some people will consider might affect their prod's reliability, some of which others might consider as security-related for their specific environment and others which will have no interest at all in what it fixes. I'm sorry but we spend time trying to detail all this in the announces so that users don't have to go through the changelog, it's hard to do more. If you have doubts and need an operation slot to update, better get used to ask for one two or three weeks after each update and you'll stay quite up to date without having to bother about any risk. If it's too hard to obtain an operations slot, then better stick to older, slower moving branches, that's why we continue to maintain them. It's not rare to find 1.6 in prod with one year of uptime or more these days and even 1.8 with 6 months or more. Willy
Re: Product Info
I think the point Willy tried to make is that it should be handled the same way regardless of being a security patch or not. All fixes are important - so see them as "security" fixes for bugs if you like. On 06/11/2019, 10.04, "apcoeproductnotificati...@wellsfargo.com" wrote: Hi Willy, Thanks for the info but honestly I am not focusing only on security fix, I need confirmation whether 2.0.8 is security patch or discretionary patch so that I can work on it accordingly on the basis of patch type. Regards, Anurag -Original Message- From: Willy Tarreau Sent: Wednesday, November 6, 2019 2:15 PM To: APCoE Product Notifications Cc: xro...@gmail.com; haproxy@formilux.org; Na, Anurag Subject: Re: Product Info On Wed, Nov 06, 2019 at 08:09:55AM +, apcoeproductnotificati...@wellsfargo.com wrote: > Hi Rob/Thomas, > Good day!! > > Thanks for the update, so as per the link the current patch is 2.0.8 > released on 23-10-2019, request you to please confirm whether this > patch is also a security patch and fixing any vulnerability (please > provide CVE if available) or not as it has one major bug fix in the release notes. Well, it was marked security since considered as such by the reporter eventhough it requires you to use a vulnerable server and to purposely write a bogus configuration, so my personal opinion on it is that it's very minor compared to all the issues we fix on a daily basis. In addition, please note that ALL FIXES ARE IMPORTANT and that if you're trying to only pick fixes explicitly marked as security, you'll end up with the most bogus load balancer on earth, and you'd rather not do this at all if you care for your site's availability. Focusing on CVEs only is part of what Linus Torvalds calls the "security circus" and I fully agree with him on that, considering how harmful most bugs can be for production and which are dropped by people focusing on CVE only and who instead pick irrelevant stuff because these have a "security" sticker. Also please have a look at this presentation by GregKH explaining the ridiculous situation we've reached with CVE nowadays: https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/ In short if you're wondering what patch to pick, you WILL eventually cause some disaster on your production that only YOU will be responsible for, by having deliberately rejected important fixes. You'd rather rely on up-to-date releases, either from sources if you build yourself, or from distro maintainers if you prefer to use pre-built packages. The project maintainers devote a lot of time maintaining stable branches containing only fixes precisely so that nobody has to duplicate this boring and dangerous job. Note that if you fear regressions, it's normal. Nobody likes to face them. In this case, just wait one week or even one month for others to deploy a new version before you do so, and you'll know if you're taking any risk. Everyone does this depending on the criticity. What is certain is that by not updating you're taking the risk to hit any of the hundreds of bugs that are known and fixed upstream. Willy
RE: Product Info
Hi Willy, Thanks for the info but honestly I am not focusing only on security fix, I need confirmation whether 2.0.8 is security patch or discretionary patch so that I can work on it accordingly on the basis of patch type. Regards, Anurag -Original Message- From: Willy Tarreau Sent: Wednesday, November 6, 2019 2:15 PM To: APCoE Product Notifications Cc: xro...@gmail.com; haproxy@formilux.org; Na, Anurag Subject: Re: Product Info On Wed, Nov 06, 2019 at 08:09:55AM +, apcoeproductnotificati...@wellsfargo.com wrote: > Hi Rob/Thomas, > Good day!! > > Thanks for the update, so as per the link the current patch is 2.0.8 > released on 23-10-2019, request you to please confirm whether this > patch is also a security patch and fixing any vulnerability (please > provide CVE if available) or not as it has one major bug fix in the release > notes. Well, it was marked security since considered as such by the reporter eventhough it requires you to use a vulnerable server and to purposely write a bogus configuration, so my personal opinion on it is that it's very minor compared to all the issues we fix on a daily basis. In addition, please note that ALL FIXES ARE IMPORTANT and that if you're trying to only pick fixes explicitly marked as security, you'll end up with the most bogus load balancer on earth, and you'd rather not do this at all if you care for your site's availability. Focusing on CVEs only is part of what Linus Torvalds calls the "security circus" and I fully agree with him on that, considering how harmful most bugs can be for production and which are dropped by people focusing on CVE only and who instead pick irrelevant stuff because these have a "security" sticker. Also please have a look at this presentation by GregKH explaining the ridiculous situation we've reached with CVE nowadays: https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/ In short if you're wondering what patch to pick, you WILL eventually cause some disaster on your production that only YOU will be responsible for, by having deliberately rejected important fixes. You'd rather rely on up-to-date releases, either from sources if you build yourself, or from distro maintainers if you prefer to use pre-built packages. The project maintainers devote a lot of time maintaining stable branches containing only fixes precisely so that nobody has to duplicate this boring and dangerous job. Note that if you fear regressions, it's normal. Nobody likes to face them. In this case, just wait one week or even one month for others to deploy a new version before you do so, and you'll know if you're taking any risk. Everyone does this depending on the criticity. What is certain is that by not updating you're taking the risk to hit any of the hundreds of bugs that are known and fixed upstream. Willy
Re: Product Info
On Wed, Nov 06, 2019 at 08:09:55AM +, apcoeproductnotificati...@wellsfargo.com wrote: > Hi Rob/Thomas, > Good day!! > > Thanks for the update, so as per the link the current patch is 2.0.8 released > on 23-10-2019, request you to please confirm whether this patch is also a > security patch and fixing any vulnerability (please provide CVE if available) > or not as it has one major bug fix in the release notes. Well, it was marked security since considered as such by the reporter eventhough it requires you to use a vulnerable server and to purposely write a bogus configuration, so my personal opinion on it is that it's very minor compared to all the issues we fix on a daily basis. In addition, please note that ALL FIXES ARE IMPORTANT and that if you're trying to only pick fixes explicitly marked as security, you'll end up with the most bogus load balancer on earth, and you'd rather not do this at all if you care for your site's availability. Focusing on CVEs only is part of what Linus Torvalds calls the "security circus" and I fully agree with him on that, considering how harmful most bugs can be for production and which are dropped by people focusing on CVE only and who instead pick irrelevant stuff because these have a "security" sticker. Also please have a look at this presentation by GregKH explaining the ridiculous situation we've reached with CVE nowadays: https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/ In short if you're wondering what patch to pick, you WILL eventually cause some disaster on your production that only YOU will be responsible for, by having deliberately rejected important fixes. You'd rather rely on up-to-date releases, either from sources if you build yourself, or from distro maintainers if you prefer to use pre-built packages. The project maintainers devote a lot of time maintaining stable branches containing only fixes precisely so that nobody has to duplicate this boring and dangerous job. Note that if you fear regressions, it's normal. Nobody likes to face them. In this case, just wait one week or even one month for others to deploy a new version before you do so, and you'll know if you're taking any risk. Everyone does this depending on the criticity. What is certain is that by not updating you're taking the risk to hit any of the hundreds of bugs that are known and fixed upstream. Willy
RE: Product Info
Hi Rob/Thomas, Good day!! Thanks for the update, so as per the link the current patch is 2.0.8 released on 23-10-2019, request you to please confirm whether this patch is also a security patch and fixing any vulnerability (please provide CVE if available) or not as it has one major bug fix in the release notes. Regards, Anurag -Original Message- From: Willy Tarreau Sent: Wednesday, November 6, 2019 12:22 PM To: Rob Thomas Cc: APCoE Product Notifications ; haproxy@formilux.org; Na, Anurag Subject: Re: Product Info On Wed, Nov 06, 2019 at 05:32:26AM +1000, Rob Thomas wrote: > "Prior to" means "before". So 2.0.6 is when it was fixed. Yep, and by the way, you should use any newer 2.0.X release which will contain many more important fixes than this one that is unlikely to hit anyone outside of a lab purposely built to trigger it (since "http-reuse always" is clearly documented as "must not use with known non-compliant servers"). If unsure, it's always good to check for known fixes here: http://www.haproxy.org/bugs/bugs-2.0.html Willy
