From: Aurelien DARRAGON <adarragon@haproxy.com>
Date: Mon, 7 Apr 2025 10:00:03 +0000 (+0200)
Subject: BUG/MINOR: log: fix CBOR encoding with LOG_VARTEXT_START() + lf_encode_chunk()
X-Git-Tag: v3.2-dev10~15
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9e8444b730e9b24e73f1f78d269f5001a34bd98d;p=thirdparty%2Fhaproxy.git

BUG/MINOR: log: fix CBOR encoding with LOG_VARTEXT_START() + lf_encode_chunk()

There have been some reports that using %HV logformat alias with CBOR
encoder would produce invalid CBOR payload according to some CBOR
implementations such as "cbor.me". Indeed, with the below log-format:

  log-format "%{+cbor}o %(protocol)HV"

And the resulting CBOR payload:

  BF6870726F746F636F6C7F48485454502F312E31FFFF

cbor.me would complain with: "bytes/text mismatch (ASCII-8BIT != UTF-8) in
streaming string") error message.

It is due to the version string being first announced as text, while CBOR
encoder actually encodes it as byte string later when lf_encode_chunk()
is used.

In fact it affects all patterns combining LOG_VARTEXT_START() with
lf_encode_chunk() which means  %HM, %HU, %HQ, %HPO and %HP are also
affected. To fix the issue, in _lf_encode_bytes() (which is
lf_encode_chunk() helper), we now check if we are inside a VARTEXT (we
can tell it if ctx->in_text is true), in which case we consider that we
already announced the current data as regular text so we keep the same
type to encode the bytes from the chunk to prevent inconsistencies.

It should be backported in 3.0
---

diff --git a/src/log.c b/src/log.c
index 7445ada0b..ca8716d20 100644
--- a/src/log.c
+++ b/src/log.c
@@ -2266,7 +2266,7 @@ static char *_lf_encode_bytes(char *start, char *stop,
 		encode_byte = _lf_map_escape_byte;
 
 	if (ctx->options & LOG_OPT_ENCODE_CBOR) {
-		if (!bytes_stop) {
+		if (!bytes_stop || ctx->in_text) {
 			/* printable chars: use cbor text */
 			cbor_string_prefix = 0x60;
 		}