[PATCH] CLEANUP: mqtt: fix typo in macro name
Hello,
Found this typo in macro name :)
BTW, in mqtt.c mqtt_read_varint(), "off" is initialized to 0, but
initialized again in the for loop, which results in a dead assignment.
I believe this is done on purpose, as some sort of defensive
programming, so I didn't touch it, but wanted to bring attention to it,
in case it is not something wanted.
Cheers,
~Nicolas
>From 1c7694831f5d0a89d3250e6c9872b68ddc170a72 Mon Sep 17 00:00:00 2001
From: Nicolas CARPi
Date: Tue, 27 Aug 2024 21:51:26 +0200
Subject: [PATCH] CLEANUP: mqtt: fix typo in MQTT_REMAINING_LENGHT_MAX_SIZE
There was a typo in the macro name, where LENGTH was incorrectly
written. This didn't cause any issue because the typo appeared in all
occurrences in the codebase.
---
include/haproxy/mqtt-t.h | 2 +-
src/mqtt.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/haproxy/mqtt-t.h b/include/haproxy/mqtt-t.h
index 3af2d1158..030a29b74 100644
--- a/include/haproxy/mqtt-t.h
+++ b/include/haproxy/mqtt-t.h
@@ -118,7 +118,7 @@ enum {
/* MQTT minimal packet size */
#define MQTT_MIN_PKT_SIZE 2
-#define MQTT_REMAINING_LENGHT_MAX_SIZE 4
+#define MQTT_REMAINING_LENGTH_MAX_SIZE 4
/* list of supported capturable Field Names and configuration file string */
enum {
diff --git a/src/mqtt.c b/src/mqtt.c
index 5688296e5..7af0c 100644
--- a/src/mqtt.c
+++ b/src/mqtt.c
@@ -238,7 +238,7 @@ static inline struct ist mqtt_read_4byte_int(struct ist
parser, uint32_t *i)
* Thus each byte encodes 128 values and a "continuation bit".
*
* The maximum number of bytes in the Remaining Length field is four
- * (MQTT_REMAINING_LENGHT_MAX_SIZE).
+ * (MQTT_REMAINING_LENGTH_MAX_SIZE).
*
* is supposed to point to the first byte of the integer. On success
* the integer is stored in <*i> and the new parser state is returned. On
@@ -251,7 +251,7 @@ static inline struct ist mqtt_read_varint(struct ist
parser, uint32_t *i)
off = m = 0;
if (i)
*i = 0;
- for (off = 0; off < MQTT_REMAINING_LENGHT_MAX_SIZE && istlen(parser);
off++) {
+ for (off = 0; off < MQTT_REMAINING_LENGTH_MAX_SIZE && istlen(parser);
off++) {
uint8_t byte = (uint8_t)*istptr(parser);
if (i) {
@@ -265,7 +265,7 @@ static inline struct ist mqtt_read_varint(struct ist
parser, uint32_t *i)
break;
}
- if (off == MQTT_REMAINING_LENGHT_MAX_SIZE)
+ if (off == MQTT_REMAINING_LENGTH_MAX_SIZE)
return IST_NULL;
return parser;
}
--
2.46.0
[PATCH] CLEANUP: haproxy: fix typos in code comment
Hello, Found these two typos while browsing the code :) Wanted to see how haproxy gets random bytes. That seed initialization code really goes out of its way to grab all entropy it can find! ^^ Best, ~Nico >From b71acb32c4122819d50dac11ae60bb5cac1faba8 Mon Sep 17 00:00:00 2001 From: Nicolas CARPi Date: Tue, 27 Aug 2024 22:02:17 +0200 Subject: [PATCH] CLEANUP: haproxy: fix typos in code comment Use "from" instead of "form" in ha_random_boot function code comments. --- src/haproxy.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/haproxy.c b/src/haproxy.c index f7bb5b5d8..21cdcb340 100644 --- a/src/haproxy.c +++ b/src/haproxy.c @@ -1417,11 +1417,11 @@ static void ha_random_boot(char *const *argv) m += 4; } - /* stack address (benefit form operating system's ASLR) */ + /* stack address (benefit from operating system's ASLR) */ l = (unsigned long)&m; memcpy(m, &l, sizeof(l)); m += sizeof(l); - /* argv address (benefit form operating system's ASLR) */ + /* argv address (benefit from operating system's ASLR) */ l = (unsigned long)&argv; memcpy(m, &l, sizeof(l)); m += sizeof(l); -- 2.46.0
Re: [PATCH] BUG/MINOR: stats-html: improve markup and fix css in dark mode
Hi Willy, On 20 Aug, Willy Tarreau wrote: > Normally it's preferable to make one commit per functional change. Noted. Here are three patches then. I've taken care of explaining the reasoning behind each of these changes in the commit messages, which should answer your interrogations! :) Cheers, ~Nicolas >From c3f0cb4be4d5802cc3e63d4501c17be1b1392ca1 Mon Sep 17 00:00:00 2001 From: Nicolas CARPi Date: Tue, 20 Aug 2024 15:20:10 +0200 Subject: [PATCH 3/3] BUG/MINOR: stats: add lang attribute to html tag The "html" element of the stats page was missing a "lang" attribute. This change specifies the "en" value, which corresponds to english language. It is also a required element for WCAG Success Criterion 3.1.1, which renders the web more accessible through a set of requirements. In this case it allows assistive technologies such as screen readers to determine the language of the page. MDN page: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/lang HTML standard: https://html.spec.whatwg.org/multipage/dom.html#attr-lang WCAG criterion: https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html --- src/stats-html.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/stats-html.c b/src/stats-html.c index c69fb9d2a..23cfb91a0 100644 --- a/src/stats-html.c +++ b/src/stats-html.c @@ -60,7 +60,7 @@ void stats_dump_html_head(struct appctx *appctx) /* WARNING! This must fit in the first buffer !!! */ chunk_appendf(chk, "\n" - "Statistics Report for " PRODUCT_NAME "%s%s\n" + "Statistics Report for " PRODUCT_NAME "%s%s\n" "\n" "\n" "
[PATCH] BUG/MINOR: stats-html: improve markup and fix css in dark mode
Hello, Please find a patch attached, along with a screenshot to illustrate the dark mode issue. Best, ~Nicolas PS: previously sent from my other email, but it seems to be hit-or-miss so let's try from this address instead. >From 96f5e7951995be8216ecee81968b0f2c7fe0141a Mon Sep 17 00:00:00 2001 From: Nicolas CARPi Date: Tue, 20 Aug 2024 10:39:17 +0200 Subject: [PATCH] BUG/MINOR: stats-html: improve markup and fix css in dark mode This patch concerns the HTML stats page: * Update the Doctype to a modern one * Add the "lang" attribute to the "html" tag. This is required by WCAG Success Criterion 3.1.1 (accessibility standard) * Fix the text color in dark mode for the Scope input field --- src/stats-html.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/stats-html.c b/src/stats-html.c index e27ff8e40..23cfb91a0 100644 --- a/src/stats-html.c +++ b/src/stats-html.c @@ -59,9 +59,8 @@ void stats_dump_html_head(struct appctx *appctx) /* WARNING! This must fit in the first buffer !!! */ chunk_appendf(chk, - "http://www.w3.org/TR/html4/loose.dtd\";>\n" - "Statistics Report for " PRODUCT_NAME "%s%s\n" + "\n" + "Statistics Report for " PRODUCT_NAME "%s%s\n" "\n" "\n" "
Re: [PATCH] DOC: fix incorrect english in lua.txt
Sending it again because it seems it never reached the mailing list for some reason!? On 13 Aug, Nicolas CARPi wrote: > Dear maintainers, > > Please find attached a patch for a few mistakes I found in doc/lua.txt > file. > > Best, > ~Nicolas >From f9cff910630851658a9f126caf1009e08dec Mon Sep 17 00:00:00 2001 From: Nicolas CARPi Date: Tue, 13 Aug 2024 22:57:56 +0200 Subject: [PATCH] DOC: fix incorrect english in lua.txt This commit fixes some typos, grammatical errors and unusual english such as "can not" instead of preferred "cannot". --- doc/lua.txt | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/doc/lua.txt b/doc/lua.txt index 5d41a30cf..9440dc83b 100644 --- a/doc/lua.txt +++ b/doc/lua.txt @@ -24,8 +24,8 @@ However, this can be read by Lua beginners. Some examples are detailed. Why a scripting language in HAProxy === -HAProxy 1.5 makes at possible to do many things using samples, but some people -want to more combining results of samples fetches, programming conditions and +HAProxy 1.5 makes it possible to do many things using samples, but some people +want to more by combining results of samples fetches, programming conditions and loops which is not possible. Sometimes people implement these functionalities in patches which have no meaning outside their network. These people must maintain these patches, or worse we must integrate them in the HAProxy @@ -135,7 +135,7 @@ these functions: These functions are the execution entry points. HTTP action must be used for manipulating HTTP request headers. This action -can not manipulates HTTP content. It is dangerous to use the channel +cannot manipulates HTTP content. It is dangerous to use the channel manipulation object with an HTTP request in an HTTP action. The channel manipulation can transform a valid request in an invalid request. In this case, the action will never resume and the processing will be frozen. HAProxy @@ -155,7 +155,7 @@ with only one stream, HAProxy seems to run fine. When the code is used with production stream, HAProxy encounters some slow processing, and it cannot hold the load. -However, during the initialisation state, you can obviously using blocking +However, during the initialisation state, you can obviously use blocking functions. There are typically used for loading files. The list of prohibited standard Lua functions during the runtime contains all @@ -219,7 +219,7 @@ I executed a Lua loop between 10 seconds with different values for the 10| 710 100 | 710 -The result showed that from 9000 instructions between two interrupt, we reached +The result showed that from 9000 instructions between two interrupts, we reached a ceil, so the default parameter is 10 000. When HAProxy interrupts the Lua processing, we have two states possible: @@ -524,9 +524,9 @@ server, and processing the many errors which can occurs during these exchanges. HAProxy is not designed for having a third connection established to a third party server. -The solution consist to put the main stream in pause waiting for the end of the -exchanges with the third connection. This is completed by a signal between -internal tasks. The following graph shows the HAProxy Lua socket: +The solution consists of putting the main stream in pause, waiting for the end +of the exchanges with the third connection. This is completed by a signal +between internal tasks. The following graph shows the HAProxy Lua socket: ++ @@ -615,7 +615,7 @@ Start point --- The HAProxy global directive "lua-load " allows to load an Lua file. This -is the entry point. This load become during the configuration parsing, and the +is the entry point. This load occurs during the configuration parsing, and the Lua file is immediately executed. All the register_*() functions must be called at this time because they are used -- 2.46.0
Re: [PR] Create SECURITY.md
Hello all, I wrote a blog post regarding the availability of this file for the biggest 5000 websites. Have a look if you're interested: https://www.deltablot.com/posts/state-of-security-txt/ Best, ~Nicolas
Re: [PR] Create SECURITY.md
Hello list, This PR made me think about the new security.txt standard - or at least proposed standard: https://securitytxt.org/ Basically, you serve a text file at .well-known/security.txt, and this should be the first place to look for a contact to send security reports to the dev team by security researchers. It is also where entities such as ANSSI will try and contact you, as explained on this page: https://www.cert.ssi.gouv.fr/signalements/. I've seen their bot in my logs trying to fetch this URL, which prompted me to add it to my websites. This message is for the maintainers of haproxy.org, but for anyone reading and interested in adding it, this is what I use: acl securitytxt-acl path_beg /.well-known/security.txt http-request return status 200 content-type text/plain string "Contact: mailto:y...@company.com\n[RestOfTheFile]\n"; if securitytxt-acl Super simple to add and very unlikely to break anything because of the well-known "namespacing". I think this would be a suitable addition to haproxy.org because the Security or Contact portions of haproxy.org don't mention any secure way to report a vuln. I'm gonna add secur...@haproxy.org in copy of this email to see if it bounces ^^ Best, ~Nicolas On 03 Aug, PR Bot wrote: > Dear list! > > Author: Valen1393 > Number of patches: 1 > > This is an automated relay of the Github pull request: >Create SECURITY.md > > Patch title(s): >Create SECURITY.md > > Link: >https://github.com/haproxy/haproxy/pull/2661 > > Edit locally: >wget https://github.com/haproxy/haproxy/pull/2661.patch && vi 2661.patch > > Apply locally: >curl https://github.com/haproxy/haproxy/pull/2661.patch | git am - > > Description: >Sabar > > Instructions: >This github pull request will be closed automatically; patch should be >reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is >invited to comment, even the patch's author. Please keep the author and >list CCed in replies. Please note that in absence of any response this >pull request will be lost. > > -- ~Nico
Re: [PATCH] FEATURE: Adding MPTCP with option to disable it and fall-back to TCP
Hello, On 24 Apr, Dorian Craps wrote: > This attached patch uses MPTCP by default instead of TCP on Linux. The backward compatibility of MPTCP is indeed a good point toward enabling it by default. Nonetheless, I feel your message should include a discussion on the security implications of this change. As you know, v0 had security issues. v1 addresses them, and we can likely consider that new attacks targeting this protocol will pop up as it becomes widespread. In fact, that's already the case: See: CVE-2024-26708: mptcp: really cope with fastopen race or CVE-2024-26826: mptcp: fix data re-injection from stale subflow or CVE-2024-26782 kernel: mptcp: fix double-free on socket dismantle The three CVEs above are all from April 2024. Given that MPTCP v1 is relatively new (2020), and that we do not have real assurances that it is at least as secure as plain TCP, I would humbly suggest inverting the logic, and making it an opt-in option. This way, a vulnerability impacting MPTCP would only impact users that enabled it, instead of 100% of HAProxy users. In a few years, making it the default could be reconsidered. Please note that I'm simply voicing my concern as a user, and the core dev team might have a very different view about these aspects. > It sounds good to have MPTCP enabled by default Except when looking at it through the prism of the increased attack surface! ;) > IPPROTO_MPTCP is defined just in case old libC are being used and > don't have the ref. Shouldn't it be defined with a value, as per https://www.mptcp.dev/faq.html#why-is-ipproto_mptcp-not-defined ? (sorry if it's a dumb remark, I'm not a C dev) Best regards, ~Nicolas
[PATCH] DOC: configuration: grammar fixes for strict-sni
Hello, Please find attached a little patch for the "strict-sni" configuration documentation, which had incorrect grammar. Best, ~Nicolas >From 077761ca4b9b3b420ad1f635179cd747dfb7a8eb Mon Sep 17 00:00:00 2001 From: Nicolas CARPi Date: Wed, 3 Apr 2024 13:43:59 +0200 Subject: [PATCH] DOC: configuration: grammar fixes for strict-sni Fix incorrect grammar in strict-sni: * is allow -> is allowed * which match -> that matches * allows to start -> allows starting --- doc/configuration.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index 68af0a844..8ea0c50bd 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -16296,9 +16296,9 @@ ssl-min-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ] strict-sni This setting is only available when support for OpenSSL was built in. The - SSL/TLS negotiation is allow only if the client provided an SNI which match + SSL/TLS negotiation is allowed only if the client provided an SNI that matches a certificate. The default certificate is not used. This option also allows - to start without any certificate on a bind line, so an empty directory could + starting without any certificate on a bind line, so an empty directory could be used and filled later from the stats socket. See the "crt" option for more information. See "add ssl crt-list" command in the management guide. -- 2.44.0
Re: [PATCH] DOC/MINOR: userlists: musl performance
Dear Lukas, Willy, Please find another patch attached, addressing your comments. Willy: s/gcc/glibc/ Lukas: I shifted the focus on the rounds/cost solution, while still mentioning the musl issue, as this problem is clearly more visible on Alpine Linux, as the github issues show. Cheers, ~Nico >From 005baaf717fc3e345ff02e9adcbfe169ae17dfb7 Mon Sep 17 00:00:00 2001 From: Nicolas CARPi Date: Mon, 12 Feb 2024 18:03:52 +0100 Subject: [PATCH] DOC/MINOR: userlists: mention solutions to high cpu with hashes This change adds a paragraph to the documentation regarding "userlists" and the use of hashed password value. It indicates what a user can do to address the high CPU cost of having to calculate the hash at each request, such as reducing the number of rounds or the cost complexity, if the algorithm allows for it. I believe it is necessary to mention how the musl C library impacts performance of hashing functions, as this has already led to a few issues: https://github.com/haproxy/haproxy/issues/1298 https://github.com/haproxy/haproxy/issues/2008 https://github.com/haproxy/haproxy/issues/2251 The performance impact is significant enough to mention it. --- doc/configuration.txt | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index 937d2a4b7..2eef819e2 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -3992,7 +3992,15 @@ user [password|insecure-password ] designed to be expensive to compute to achieve resistance against brute force attacks. They do not simply salt/hash the clear text password once, but thousands of times. This can quickly become a major factor in HAProxy's - overall CPU consumption! + overall CPU consumption, and can even lead to application crashes! + + To address the high CPU usage of hash functions, one approach is to reduce + the number of rounds of the hash function (SHA family algorithms) or decrease + the "cost" of the function, if the algorithm supports it. + + As a side note, musl (e.g. Alpine Linux) implementations are known to be + slower than their glibc counterparts when calculating hashes, so you might + want to consider this aspect too. Example: userlist L1 -- 2.43.0
[PATCH] DOC/MINOR: userlists: musl performance
Hello everyone, Please find attached my very first patch to the documentation. Hope I did everything good! :) Based on a comment from @bugre: https://github.com/haproxy/haproxy/issues/2251#issuecomment-1716594046 (and also because I've been bitten by this!) Best, ~Nicolas >From 04844e6eee725ff8bfe4ec62578e24649f020ec9 Mon Sep 17 00:00:00 2001 From: Nicolas CARPi Date: Mon, 12 Feb 2024 12:45:15 +0100 Subject: [PATCH] DOC/MINOR: userlists: mention performance penalty of musl This change adds a paragraph to the documentation regarding "userlists" and the use of hashed password value. It is necessary to mention how the Alpine/musl C library impacts performance of hashing functions, as this has already led to a few issues: https://github.com/haproxy/haproxy/issues/1298 https://github.com/haproxy/haproxy/issues/2008 https://github.com/haproxy/haproxy/issues/2251 This change indicates clearly the shortcomings of musl, and proposes workarounds such as reducing the number of rounds or the cost complexity, if the algorithm allows for it. --- doc/configuration.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/configuration.txt b/doc/configuration.txt index 937d2a4b7..9864a49a5 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -3994,6 +3994,12 @@ user [password|insecure-password ] but thousands of times. This can quickly become a major factor in HAProxy's overall CPU consumption! + Furthermore, there is a significant performance penalty when using a musl + variant (for instance with the Alpine linux distribution), as the musl code for + these hashing functions is less performant/optimized than its GCC + counterpart. When using musl, reducing the number of rounds or the "cost" of + the algorithm used can help a lot with the CPU usage. + Example: userlist L1 group G1 users tiger,scott -- 2.43.0
Re:
Dear Chic Closet, Hello, and thank you for reaching out to us regarding your need for a proxy. We appreciate your interest and are eager to assist you, but to provide you with the best possible solution, we need a bit more information about your specific requirements and the context of your needs. Your initial message, "I need proxy", though concise, leaves several critical aspects open for interpretation. There are various types of proxy services, each catering to different needs and scenarios. For instance: -Type of Proxy: Are you looking for a residential proxy, a datacenter proxy, or perhaps a mobile proxy? Each type offers different advantages and is suitable for different use cases. -Purpose of Use: Understanding your intended use of the proxy is crucial. Are you looking to enhance your online privacy, bypass geographical restrictions, perform web scraping, or something else entirely? -Required Geolocation: If you need a proxy for accessing content or services from a specific geographic location, please let us know the required country or region. -Volume and Scale: Are you looking for a single proxy or a pool of proxies? Knowing the scale of your requirement will help us suggest the most efficient and cost-effective solution. -Technical Requirements: Depending on your technical setup and proficiency, you might need a user-friendly solution or one that offers advanced customization and integration capabilities. -Security and Anonymity Levels: Different proxies offer varying levels of security and anonymity. It's important to align these with your needs, especially if handling sensitive data. -Budget Constraints: Understanding your budget will help us recommend a solution that offers the best value for your investment. We understand that navigating the world of proxies can be complex, especially with the multitude of options available. Our team is committed to guiding you through this process and ensuring that you find a proxy service that perfectly aligns with your specific needs and objectives. Could you please provide us with more details regarding the points mentioned above? This information will enable us to offer a tailored recommendation and ensure that we meet your expectations to the fullest. Looking forward to your response and hoping to assist you soon. Warm regards, ~Nico On 16 Jan, Chic Closet wrote: > Hello, > I need proxy
Re: PEM Certificates for HAproxy
On 29 Apr, Shawn Heisey wrote: > I know that a fresh install can be instantly operational with TLS, > suggesting that it is not generating them on the fly ... so I really wonder > how secure the default params are. I wonder what is being used when there > are no params in the cert file. Does it get something hardcoded and use that > until params generated in the background can be swapped in? You'll want to have a look at this issue: https://github.com/haproxy/haproxy/issues/1604 Indeed HAProxy has default ones, and reading the issue and comments of Lukas you'll understand why DH params are a thing of the past (if you use modern ciphers), and why generating them yourself is not even that great to begin with. (I'm the author of the issue btw) Best, ~Nico
Re: Blocking log4j CVE with HAProxy
On 13 Dec, Jonathan Matthews wrote:
> I believe there are string casing operators available, leading to
> options like "${j{$lower:N}di:ldap://...";.
Indeed. Maybe this can help, it's the "Bypass WAF" part of the POC[0]:
${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://asdasd.asdasd.asdasd/poc}
${${::-j}ndi:rmi://asdasd.asdasd.asdasd/ass}
${jndi:rmi://adsasd.asdasd.asdasd}
${${lower:jndi}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
${${lower:${lower:jndi}}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://adsasd.asdasd.asdasd/poc}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://xxx.xx/poc}
So if one can manage to match all of that, it could work.
Of course this block in the POC is immediatly followed by:
Don't trust the web application firewall. ;)
[0]
https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce#bypass-waf
Best,
~Nico
Re: [PATCH] move VTest installation to scripts/build-vtest.sh
> I compared several times, git clone is faster In my hands curl is the fastest option compared to git clone. Wouldn't "git clone --depth 1" be a good option to consider here? It avoids getting the full history. ~Nico
Re: [PATCH} suppress "misleading indentation" gcc 11 warning
On 18 Dec, Tim Düsterhus wrote: > I'm not sure I understand the question correctly, but I assume you mean > the highlighting due to me directly linking to the lines? Arf, didn't realize that... Thanks! ~Nico
Re: [PATCH} suppress "misleading indentation" gcc 11 warning
Dear Tim, > It'll probably get a quite bit smaller if you'd add a configuration file > that configures the indentation to happen using tabs instead of spaces. You're correct. It was just a quick and dirty try with default config to see if things can still compile after running it, I have no intention on proposing a patch. :) > But even then it stomps over stuff like `a_eq_b` in > contrib/ip6range/ip6range.c: Could you please enlighten me as to why the diff of this function is of a different color from the rest? First time I see this. Cheers and thanks to all the contributors for this great piece of software! ~Nico
Re: [PATCH} suppress "misleading indentation" gcc 11 warning
Dear list, For purely illustration purposes, this is the kind of diff that would be generated if one were to clang-format all the .c files: https://github.com/deltablot/haproxy/commit/878ba41e4742b39034686d2b6feb3c561edeb72a Showing 195 changed files with 177,997 additions and 174,367 deletions. oO ! Have a nice evening all (or day depending on your TZ). ~Nicolas On 17 Dec, Nicolas CARPi wrote: > Hey Tim, > > Sorry I wasn't clear in my message, I should have written that the doc > needs to be updated only if you ever chose to add this formatting check. > But as you stated, it would be a lot of work and commit noise for little > benefit and I understand completely why you would not want to do that. > > It's the kind of thing that benefit fresh projects. > > Best regards, > ~Nicolas > > > On 17 Dec, Tim Düsterhus wrote: > > Nicolas, > > > > Am 17.12.20 um 15:53 schrieb Nicolas CARPi: > > > To fail or not to fail. That is the question! :) > > > > > > I'd add to that the contributor documentation should be updated to add > > > steps for having a clang-format (or any other formatter) as a git > > > pre-hook. > > > > As someone who actually contributes to the C source code of HAProxy I > > disagree. > > > > 1) The codebase is fairly old and already has formatting issues (Tabs > > and Spaces mixed within single files). Initially running the > > autoformatter will create merge / rebase conflicts all over the place. > > 2) A few source code locations are intentionally manually formatted like > > they are. Autoformatters tend to stomp over that, breaking this > > intentional formatting, decreasing readability. > > 3) Clearly the actual contributors are not unhappy with the current > > situation, otherwise they would already have introduced such an > > autoformatting. > > 4) It would require contributors to set up that autoformatter (in the > > correct version, with the correct config, etc.), creating work for a > > small benefit. > > > > Best regards > > Tim Düsterhus > > > > > I'm partial to failing the build (in CI) to avoid using further > > > electricity if the first step (syntax) fails, as another commit fixing > > > the syntax will likely come after. > > > > > > ~Nico > > > > > > > -- > ~Nico > -- ~Nico
Re: [PATCH} suppress "misleading indentation" gcc 11 warning
Hey Tim, Sorry I wasn't clear in my message, I should have written that the doc needs to be updated only if you ever chose to add this formatting check. But as you stated, it would be a lot of work and commit noise for little benefit and I understand completely why you would not want to do that. It's the kind of thing that benefit fresh projects. Best regards, ~Nicolas On 17 Dec, Tim Düsterhus wrote: > Nicolas, > > Am 17.12.20 um 15:53 schrieb Nicolas CARPi: > > To fail or not to fail. That is the question! :) > > > > I'd add to that the contributor documentation should be updated to add > > steps for having a clang-format (or any other formatter) as a git > > pre-hook. > > As someone who actually contributes to the C source code of HAProxy I > disagree. > > 1) The codebase is fairly old and already has formatting issues (Tabs > and Spaces mixed within single files). Initially running the > autoformatter will create merge / rebase conflicts all over the place. > 2) A few source code locations are intentionally manually formatted like > they are. Autoformatters tend to stomp over that, breaking this > intentional formatting, decreasing readability. > 3) Clearly the actual contributors are not unhappy with the current > situation, otherwise they would already have introduced such an > autoformatting. > 4) It would require contributors to set up that autoformatter (in the > correct version, with the correct config, etc.), creating work for a > small benefit. > > Best regards > Tim Düsterhus > > > I'm partial to failing the build (in CI) to avoid using further > > electricity if the first step (syntax) fails, as another commit fixing > > the syntax will likely come after. > > > > ~Nico > > > -- ~Nico
Re: [PATCH} suppress "misleading indentation" gcc 11 warning
To fail or not to fail. That is the question! :) I'd add to that the contributor documentation should be updated to add steps for having a clang-format (or any other formatter) as a git pre-hook. I'm partial to failing the build (in CI) to avoid using further electricity if the first step (syntax) fails, as another commit fixing the syntax will likely come after. ~Nico On 17 Dec, Илья Шипицин wrote: > Well, there are formatters like clang format or similar. We can even run them > in pipeline. But it has nothing to do with compilation and we should not fail > build because of that > > On Thu, Dec 17, 2020, 5:35 PM Nicolas CARPi wrote: > > Dear list, > > Formatting on PRs is a hot topic, but IMHO it should be done by an > automated tool so we can forget about it and focus on the core of the > PR, not the style. A git pre-hook would be best. > > > I'd say it is friendly mood not to push people to comply formatting (who > cares > > of indentation ?) > I disagree with that view. No need to be as hardcore as go who won't > compile if there is an indentation issue, but still, I think it helps > readability and prevent bugs to have correct indentation (an incorrect > one might make you think that a block is part of a loop, when it is > not). > > Regards, > ~Nicolas CARPi > > PS: go ships with a formatting tool so this is a non issue in that > language > > > On 17 Dec, Илья Шипицин wrote: > > well, I met some projects that are insane on formatting. > > it is funny each time, when discussing new PR "please fix your > formatting" > > (weeks spent on that), after PR is merged something is broken because of > lack > > of testing. > > > > I'd say it is friendly mood not to push people to comply formatting (who > cares > > of indentation ?) > > > > чт, 17 дек. 2020 г. в 13:05, Tim Düsterhus <[1][1]t...@bastelstu.be>: > > > > Ilya, > > > > Am 17.12.20 um 08:26 schrieb Илья Шипицин: > > > gcc 11 (delivered with fedora rawhide) introduces indentation > check. > > > it is totally harmless. > > > > > > this patch suppresses it. > > > it resolves #998 > > > might be backported to all supported branches. > > > > > > > Can we please fix the actual issue instead of suppressing the > warning? > > In fact I believe that this line is incorrectly intended: > > > > [2][2]https://github.com/haproxy/haproxy/blob/ > > a4009cd6103a92752db27c3a85051c6adcc832c1/include/import/plock.h#L236 > > > > Best regards > > Tim Düsterhus > > > > > > References: > > > > [1] mailto:[3]t...@bastelstu.be > > [2] [4]https://github.com/haproxy/haproxy/blob/ > a4009cd6103a92752db27c3a85051c6adcc832c1/include/import/plock.h#L236 > > -- > ~Nico > > > References: > > [1] mailto:t...@bastelstu.be > [2] https://github.com/haproxy/haproxy/blob/ > [3] mailto:t...@bastelstu.be > [4] > https://github.com/haproxy/haproxy/blob/a4009cd6103a92752db27c3a85051c6adcc832c1/include/import/plock.h#L236 -- ~Nico
Re: [PATCH} suppress "misleading indentation" gcc 11 warning
Dear list, Formatting on PRs is a hot topic, but IMHO it should be done by an automated tool so we can forget about it and focus on the core of the PR, not the style. A git pre-hook would be best. > I'd say it is friendly mood not to push people to comply formatting (who cares > of indentation ?) I disagree with that view. No need to be as hardcore as go who won't compile if there is an indentation issue, but still, I think it helps readability and prevent bugs to have correct indentation (an incorrect one might make you think that a block is part of a loop, when it is not). Regards, ~Nicolas CARPi PS: go ships with a formatting tool so this is a non issue in that language On 17 Dec, Илья Шипицин wrote: > well, I met some projects that are insane on formatting. > it is funny each time, when discussing new PR "please fix your formatting" > (weeks spent on that), after PR is merged something is broken because of lack > of testing. > > I'd say it is friendly mood not to push people to comply formatting (who cares > of indentation ?) > > чт, 17 дек. 2020 г. в 13:05, Tim Düsterhus <[1]t...@bastelstu.be>: > > Ilya, > > Am 17.12.20 um 08:26 schrieb Илья Шипицин: > > gcc 11 (delivered with fedora rawhide) introduces indentation check. > > it is totally harmless. > > > > this patch suppresses it. > > it resolves #998 > > might be backported to all supported branches. > > > > Can we please fix the actual issue instead of suppressing the warning? > In fact I believe that this line is incorrectly intended: > > [2]https://github.com/haproxy/haproxy/blob/ > a4009cd6103a92752db27c3a85051c6adcc832c1/include/import/plock.h#L236 > > Best regards > Tim Düsterhus > > > References: > > [1] mailto:t...@bastelstu.be > [2] > https://github.com/haproxy/haproxy/blob/a4009cd6103a92752db27c3a85051c6adcc832c1/include/import/plock.h#L236 -- ~Nico
Re: Alternatives to PayPal
Thanks Willy, it makes perfect sense. I'll sponsor other projects! :) Cheers, ~Nico On 08 Oct, Willy Tarreau wrote: > Hi, > > On Wed, Oct 07, 2020 at 11:20:25AM +0200, Sebastian Fohler wrote: > > What about a Patron account. > > > > https://www.patreon.com/europe > > > > Cause I already asked multiple times for some other means of contribution as > > well. > > That would help a great deal, makeing it easier. > > I'm supporting multiple Opensource projects already this way. > > Would that be an option? > > Well, to make things clear, first let me remind that the paypal account > is my personal account, which I have added a link to from the main page > upon request by several people willing to donate many years ago. This > has been helpful in the early days, allowing me buy some hardware to > experiment during week-ends (such as the 10G lab), and to significantly > improve the code's portability and efficiency on small systems. It used > to serve to contribute to the hosting costs as well. > > Since then the project has considerably evolved, being backed by a company > offering a much larger full-time development team. And users are well > aware of this because nowadays donations are extremely rare (in the range > of tens of dollars a year). But at the same time nowadays I do not need > them at all anymore, so I'm perfectly fine with replacing the link with > anything else. I've only been keeping it because I know that if I remove > it, the question will come back again a few months later. > > The only thing is that I am *not* going to deal with yet another task > that adds more burden, so if someone is willing to set up any account > via $whatever company, they will have to handle it and pass me the > replacement link. At least the paypal link doesn't cause me any extra > work beyond replying "thank you" to donators once in a while. Just be > aware that since donations are rare, I'm not at all convinced it will > be worth doing anything particular. And at some point a solution will > have to be found to spend the eventual money that would land there, > so someone will have to handle this, and again it's certainly not me. > > My personal suggestion would be that those who want to give a few > dollars better keep their money that they certainly need more than > most developers or contributors do, because due to the project's > nature, contributors generaly work in IT at levels at which, based on > the high quality of their contributions, they're not expected to be > starving at all (or if they do they definitely need to switch jobs as > their skills are quite sought)! If anyone is ever willing to spend a > large amount, like thousands of dollars, better hire someone to develop > some useful desired features, it will be an excellent contribution to > the project! Another great option is to contact your favorite distro's > package maintainer and propose your donation there, because distro > maintainers have been doing this thankless job for many years now and > deserve some recognition as well. For anything else, offering time to > look into bugs, testing -dev releases, improving the doc, contributing > to the wiki etc is extremely valuable and helps all contributors at > once. > > As you see, there are still plenty of options which do not require > managing any new account anywhere. > > Thanks for your support :-) > Willy > -- ~Nico
Alternatives to PayPal
Dear list, Haproxy is an amazing project and it is clear that the devs are pouring a lot of energy and time into it. As a (very) small entrepreneur, I use Haproxy to host my services and I'm quite happy with it. It is an essential part of my business. I wish to redistribute a small part of the money I generate to this project, as I believe open source projects do need this, nothing is free in this world. Unfortunately, the only way to donate is through PayPal, and like many, I have a strong aversion to this company. May I suggest setting up an OpenCollective or Liberapay account (or both)? These services also allow to be transparent about who gets what and to remunerate recurrent contributors. Let me know what you think! :) Regards, ~Nicolas CARPi
Re: [PR] SOCKS4(A)
Yes Willy, we want to know! Why the hell you keep using C and don't switch to C++? Better yet, why don't you rewrite it in Rust. The part where he explains to you how you should use functions is GOLD! :D Have a nice day everyone and thanks for the laughs alex! ~Nico On 01 Oct, Willy Tarreau wrote: > Hello, > > On Wed, Sep 30, 2020 at 10:19:32PM +0200, PR Bot wrote: > > Dear list! > > > > Author: alexzk1 > > Number of patches: 30 > > > > This is an automated relay of the Github pull request: > >SOCKS4(A) > (...) > > Description: > >So I completely understand that you will dislike what my formatter did > >there, but you can just reject. I don't care as it was paid update. > > I think it could win the contest of the funniest ever contribution > received over the last two decades! > > First, I failed to spot a single patch that does something related to what > the 2-to-8 words "commit message" claimed and this is not in any way the > formatter's fault. Second, claiming "I don't care if you pick it anyway > since I was paid to do it" makes me wonder "who's crazy enough to pay for > this, and probably to go as far as deploying it?". I mean, I'm not sure > they realized they'll have to pay you to do it again and again after each > fix that gets applied to the main tree. Well done at least if that worked :-) > > >So what it do: > >1. adds support for socks4A, if it cannot resolve > >dns localy it does ..read file "fake_host.h" > >2. you forgot to > >copy-paste setup from "backend.c" to "tcpcheck.c" for socks4. So since > >2.1 it does not do check over socks. > >I fixed that and removed > >copy-paste by doing function. > > If you have a fix to provide, please point it in this ocean of random > patches, because I can't find it. Or better, just explain what the > problem is so that someone can fix it properly :-/ > > >Also it is generic rule, if any > >piece of code met twice -> do a function. 90% of your current can be > >changed in that way. > > Excellent advice, thank you! > > >3. and at then end I have rhetoric question: > >if you invented there virtual functions and virtual table, why the > >hell you keep using C and don't switch to C++ ? > > Hehe good one :-) > > Willy > -- ~Nico
