Re: Update for https://github.com/haproxy/wiki/wiki/SPOE:-Stream-Processing-Offloading-Engine

2024-04-19 Thread William Lallemand
On Mon, Apr 15, 2024 at 10:18:19AM +0200, Aleksandar Lazic wrote:
> Hi.
> 
> The "https://github.com/criteo/haproxy-spoe-go; is archived since Nov 7,
> 2023 and there is a fork from that repo https://github.com/go-spop/spoe
> Can we add this info to the wiki page?
> 
> There is also a rust implementation
> https://github.com/vkill/haproxy-spoa-example which could be added.
> 
> If it's possible then would I add this by my self.
> 

Thanks Aleks, I add them both on the page, and set criteo's one as
unmaintained.


-- 
William Lallemand



Re: [PATCH 0/3] Add support for UUIDv7

2024-04-19 Thread Willy Tarreau
Hi Tim!

On Fri, Apr 19, 2024 at 09:01:24PM +0200, Tim Duesterhus wrote:
> Willy,
> 
> as requested in the thread "[ANNOUNCE] haproxy-3.0-dev7":
> 
> > Regarding UUIDs, though, I've recently come across UUIDv7 which I found
> > particularly interesting, and that I think would be nice to implement
> > in the uuid() sample fetch function before 3.0 is released.
> 
> No reg-tests added, as those doesn't allow meaningfully testing that the
> UUIDv7 is actually a UUIDv7. I have manually checked the output against
> https://uuid7.com/.

Oh, many thanks for this, it was still on my todo list and I sense that
the review of your patches will take me less effort than implementing
it! I'll have a look on Monday, I'm really done for this week, need to
have some sleep.

Thanks and have a nice week-end!
Willy



[PATCH 2/3] MINOR: Add `ha_generate_uuid_v7`

2024-04-19 Thread Tim Duesterhus
This function generates a version 7 UUID as per
draft-ietf-uuidrev-rfc4122bis-14.
---
 include/haproxy/tools.h |  1 +
 src/tools.c | 25 +
 2 files changed, 26 insertions(+)

diff --git a/include/haproxy/tools.h b/include/haproxy/tools.h
index cbce218dc6..4e1a6dfa3f 100644
--- a/include/haproxy/tools.h
+++ b/include/haproxy/tools.h
@@ -1057,6 +1057,7 @@ int parse_dotted_uints(const char *s, unsigned int 
**nums, size_t *sz);
 
 /* PRNG */
 void ha_generate_uuid_v4(struct buffer *output);
+void ha_generate_uuid_v7(struct buffer *output);
 void ha_random_seed(const unsigned char *seed, size_t len);
 void ha_random_jump96(uint32_t dist);
 uint64_t ha_random64(void);
diff --git a/src/tools.c b/src/tools.c
index f3b095569a..114cbf6ddf 100644
--- a/src/tools.c
+++ b/src/tools.c
@@ -5605,6 +5605,31 @@ void ha_generate_uuid_v4(struct buffer *output)
 (long long)((rnd[2] >> 14u) | ((uint64_t) rnd[3] << 18u)) 
& 0xull);
 }
 
+/* Generates a draft-ietf-uuidrev-rfc4122bis-14 version 7 UUID into chunk
+ *  which must be at least 37 bytes large.
+ */
+void ha_generate_uuid_v7(struct buffer *output)
+{
+   uint32_t rnd[3];
+   uint64_t last;
+   uint64_t time;
+
+   time = (date.tv_sec * 1000) + (date.tv_usec / 1000);
+   last = ha_random64();
+   rnd[0] = last;
+   rnd[1] = last >> 32;
+
+   last = ha_random64();
+   rnd[2] = last;
+
+   chunk_printf(output, "%8.8x-%4.4x-%4.4x-%4.4x-%12.12llx",
+(uint)(time >> 16u),
+(uint)(time & 0x),
+((rnd[0] >> 16u) & 0xFFF) | 0x7000,  // highest 4 bits 
indicate the uuid version
+(rnd[1] & 0x3FFF) | 0x8000,  // the highest 2 bits 
indicate the UUID variant (10),
+(long long)((rnd[1] >> 14u) | ((uint64_t) rnd[2] << 18u)) 
& 0xull);
+}
+
 
 /* only used by parse_line() below. It supports writing in place provided that
  *  is updated to the next location before calling it. In that case, the
-- 
2.43.2




[PATCH 3/3] MINOR: Add support for UUIDv7 to the `uuid` sample fetch

2024-04-19 Thread Tim Duesterhus
This adds support for UUIDv7 to the existing `uuid` sample fetch that was added
in 8a694b859cf98f8b0855b4aa5a50ebf64b501215.
---
 doc/configuration.txt |  3 ++-
 src/sample.c  | 40 +---
 2 files changed, 31 insertions(+), 12 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index d2d654c191..16094c194a 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -21306,7 +21306,8 @@ txn.sess_term_state : string
 uuid([]) : string
   Returns a UUID following the RFC4122 standard. If the version is not
   specified, a UUID version 4 (fully random) is returned.
-  Currently, only version 4 is supported.
+
+  Versions 4 and 7 are supported.
 
 var([,]) : undefined
   Returns a variable with the stored type. If the variable is not set, the
diff --git a/src/sample.c b/src/sample.c
index 8daa92424d..43ab003529 100644
--- a/src/sample.c
+++ b/src/sample.c
@@ -4781,10 +4781,15 @@ static int smp_check_uuid(struct arg *args, char **err)
if (!args[0].type) {
args[0].type = ARGT_SINT;
args[0].data.sint = 4;
-   }
-   else if (args[0].data.sint != 4) {
-   memprintf(err, "Unsupported UUID version: '%lld'", 
args[0].data.sint);
-   return 0;
+   } else {
+   switch (args[0].data.sint) {
+   case 4:
+   case 7:
+   break;
+   default:
+   memprintf(err, "Unsupported UUID version: '%lld'", 
args[0].data.sint);
+   return 0;
+   }
}
 
return 1;
@@ -4793,16 +4798,29 @@ static int smp_check_uuid(struct arg *args, char **err)
 // Generate a RFC4122 UUID (default is v4 = fully random)
 static int smp_fetch_uuid(const struct arg *args, struct sample *smp, const 
char *kw, void *private)
 {
-   if (args[0].data.sint == 4 || !args[0].type) {
+   long long int type = -1;
+
+   if (!args[0].type) {
+   type = 4;
+   } else {
+   type = args[0].data.sint;
+   }
+
+   switch (type) {
+   case 4:
ha_generate_uuid_v4();
-   smp->data.type = SMP_T_STR;
-   smp->flags = SMP_F_VOL_TEST | SMP_F_MAY_CHANGE;
-   smp->data.u.str = trash;
-   return 1;
+   break;
+   case 7:
+   ha_generate_uuid_v7();
+   break;
+   default:
+   return 0;
}
 
-   // more implementations of other uuid formats possible here
-   return 0;
+   smp->data.type = SMP_T_STR;
+   smp->flags = SMP_F_VOL_TEST | SMP_F_MAY_CHANGE;
+   smp->data.u.str = trash;
+   return 1;
 }
 
 /* Check if QUIC support was compiled and was not disabled by "no-quic" global 
option */
-- 
2.43.2




[PATCH 0/3] Add support for UUIDv7

2024-04-19 Thread Tim Duesterhus
Willy,

as requested in the thread "[ANNOUNCE] haproxy-3.0-dev7":

> Regarding UUIDs, though, I've recently come across UUIDv7 which I found
> particularly interesting, and that I think would be nice to implement
> in the uuid() sample fetch function before 3.0 is released.

No reg-tests added, as those doesn't allow meaningfully testing that the
UUIDv7 is actually a UUIDv7. I have manually checked the output against
https://uuid7.com/.

Best regards

Tim Duesterhus (3):
  MINOR: tools: Rename `ha_generate_uuid` to `ha_generate_uuid_v4`
  MINOR: Add `ha_generate_uuid_v7`
  MINOR: Add support for UUIDv7 to the `uuid` sample fetch

 addons/ot/src/scope.c   |  2 +-
 doc/configuration.txt   |  3 ++-
 include/haproxy/tools.h |  3 ++-
 src/flt_spoe.c  |  2 +-
 src/sample.c| 42 +
 src/tools.c | 29 ++--
 6 files changed, 63 insertions(+), 18 deletions(-)

-- 
2.43.2




[PATCH 1/3] MINOR: tools: Rename `ha_generate_uuid` to `ha_generate_uuid_v4`

2024-04-19 Thread Tim Duesterhus
This is in preparation of adding support for other UUID versions.
---
 addons/ot/src/scope.c   | 2 +-
 include/haproxy/tools.h | 2 +-
 src/flt_spoe.c  | 2 +-
 src/sample.c| 2 +-
 src/tools.c | 4 ++--
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/addons/ot/src/scope.c b/addons/ot/src/scope.c
index efe8fe29f6..8a4c02f3cf 100644
--- a/addons/ot/src/scope.c
+++ b/addons/ot/src/scope.c
@@ -113,7 +113,7 @@ struct flt_ot_runtime_context 
*flt_ot_runtime_context_init(struct stream *s, str
LIST_INIT(&(retptr->contexts));
 
uuid = b_make(retptr->uuid, sizeof(retptr->uuid), 0, 0);
-   ha_generate_uuid();
+   ha_generate_uuid_v4();
 
 #ifdef USE_OT_VARS
/*
diff --git a/include/haproxy/tools.h b/include/haproxy/tools.h
index 11082379c8..cbce218dc6 100644
--- a/include/haproxy/tools.h
+++ b/include/haproxy/tools.h
@@ -1056,7 +1056,7 @@ static inline void *my_realloc2(void *ptr, size_t size)
 int parse_dotted_uints(const char *s, unsigned int **nums, size_t *sz);
 
 /* PRNG */
-void ha_generate_uuid(struct buffer *output);
+void ha_generate_uuid_v4(struct buffer *output);
 void ha_random_seed(const unsigned char *seed, size_t len);
 void ha_random_jump96(uint32_t dist);
 uint64_t ha_random64(void);
diff --git a/src/flt_spoe.c b/src/flt_spoe.c
index 3fc058c283..b180ba2dd5 100644
--- a/src/flt_spoe.c
+++ b/src/flt_spoe.c
@@ -249,7 +249,7 @@ static const char 
*spoe_appctx_state_str[SPOE_APPCTX_ST_END+1] = {
 static char *
 generate_pseudo_uuid()
 {
-   ha_generate_uuid();
+   ha_generate_uuid_v4();
return my_strndup(trash.area, trash.data);
 }
 
diff --git a/src/sample.c b/src/sample.c
index 334782c173..8daa92424d 100644
--- a/src/sample.c
+++ b/src/sample.c
@@ -4794,7 +4794,7 @@ static int smp_check_uuid(struct arg *args, char **err)
 static int smp_fetch_uuid(const struct arg *args, struct sample *smp, const 
char *kw, void *private)
 {
if (args[0].data.sint == 4 || !args[0].type) {
-   ha_generate_uuid();
+   ha_generate_uuid_v4();
smp->data.type = SMP_T_STR;
smp->flags = SMP_F_VOL_TEST | SMP_F_MAY_CHANGE;
smp->data.u.str = trash;
diff --git a/src/tools.c b/src/tools.c
index 09de5db201..f3b095569a 100644
--- a/src/tools.c
+++ b/src/tools.c
@@ -5581,10 +5581,10 @@ void ha_random_jump96(uint32_t dist)
}
 }
 
-/* Generates an RFC4122 UUID into chunk  which must be at least 37
+/* Generates an RFC4122 version 4 UUID into chunk  which must be at 
least 37
  * bytes large.
  */
-void ha_generate_uuid(struct buffer *output)
+void ha_generate_uuid_v4(struct buffer *output)
 {
uint32_t rnd[4];
uint64_t last;
-- 
2.43.2




[ANNOUNCE] haproxy-3.0-dev8

2024-04-19 Thread Willy Tarreau
Hi,

HAProxy 3.0-dev8 was released on 2024/04/19. It added 115 new commits
after version 3.0-dev7.

3.0-dev7 showed some recent issues related to stick-tables and peers,
which mechanically inflated the number of fixes in this version (32).
Thanks to Christian Ruppert, Felipe Damasio and Ricardo Sanchez for their
quick and helpful reports BTW, because 3.0-dev7 was still warm out of the
oven that the reports started to come about problems!

Here are the main changes:
- the stick-tables issues and peers problems were addressed. However, this
  also led to other bugs being discovered on peers, related to recent
  changes and that were fixed as well. Next week we'll have an in-depth
  review there to make sure there is no other one. At this point we're not
  aware of any remaining one in this area.

- another crash was caused by the recent ring changes and affected the
  startup logs. Technically speaking, upon reload the buffer was
  reallocated of the previous usable size, so 192 bytes were lost upon
  every process switchover, which didn't cope well with ring buffers that
  were full of logs...

- the evports polling system on Solaris uses a strange API and didn't cope
  well with signals and could lose some event reports resulting in an
  inconsistency between the internal FD polling state and the one in the
  system, which was visible as spinning loops when using external checks.
  In addition, it was found that there was a leftover from a debugging
  session since day 1 there, by which it would only handle a single event
  per loop, making it very inefficient!

- the other issues fixed in various areas are a bit more technical and out
  of scope here, and will be more detailed when backported to their
  respective stable branches.

- as I mentioned last week, the makefile was updated so that it is easier
  to pass CFLAGS/LDFLAGS etc and no longer necessary to hack into
  DEBUG_CFLAGS and such cryptic variables. The few that were dropped will
  cause the emission of warning and an advice when set so that packagers
  will quickly figure what to change. William even suggested that we bail
  on error when ERR=1, which I agree with, but it was not done yet. Also,
  now if an unknown USE_foo= option is passed on the make command line, a
  warning will mention that it's ignored. This should avoid common typos
  like inverted words in long names.

- some of the internal "shutdown" API was cleaned up (one function instead
  of one per direction), in the hope that it will at least pave the way to
  more easily forward errors verbatim between sides (e.g. gRPC events).

- a new "crt-store" configuration section is supported, it allows to
  declare certificates by specifying the path for each element. The aim
  is essentially to decorellate the storage from the instantiation, both
  of which are currently correlated in crt-lists, and to allow easier
  specification of individual components. For example:

  crt-store
load crt "/crt/site1.crt" key "/keys/site1.key" ocsp "/ocsp/site1.ocsp"
load crt "/crt/site2.crt" key "/keys/site2.key"

  In addition, it's possible to set a "crt-base" and a "key-base" there so
  that the path doesn't have to be repeated on each line. The certificates
  also support aliases so that they can be referenced from a bind line with
  a more convenient names, e.g.:

  crt-store web
  crt-base /etc/ssl/certs/
  key-base /etc/ssl/private/
  load crt "site3.crt" alias "site3"
  load crt "site4.crt" key "site4.key"

  frontend in2
  bind *:443 ssl crt "@web/site3" crt "@web/site4.crt"

- the backend equivalent of the frontend keylog mechanism was implemented,
  so that it is now possible to decipher TLS captures on the backend side.
  The log-format to be used becomes a bit large, please refer to the
  example in the doc.

- some cleanup was performed on low level QUIC sending functions. Most
  notably, duplicated code is removed. The main objective is to facilitate
  the development of new features on top of these functions. As
  complement, small optimizations to avoid unnecessary function calls are
  also introduced which could improve performance slightly.

- the way the memory limitation specified by "-m" on the command line was
  handled on Linux using RLIMIT_AS got completely useless over time due to
  much more fragmented memory spaces on 64-bit platforms, ASLR, and the
  fact that it had been chosen exclusively to avoid underestimating the
  allocated buffers' cost, which originally were allocated all the time
  even when empty. But nowadays this is no longer relevant since they're
  only allocated when used. This had the nasty effect of causing OOMs way
  below the configured limit, rendering it pretty useless. Now we've
  dropped this specific case and went back to RLIMIT_DATA like on other
  OSes.

- some build warnings were addressed with older compilers.

- various other cleanups and code reorganization to help with 

Re: [PATCH 0/1] CI: switch to more recent macos version(s)

2024-04-19 Thread Willy Tarreau
On Fri, Apr 19, 2024 at 07:16:44AM +0200, Ilya Shipitsin wrote:
> let's modernize macos CI build matrix since macos-14 is available

Merged, thank you Ilya!
willy