* origin/topic/awelzel/no-null-strings-in-threading-vals:
logging/Manager: Also pass non-null vector and set
logging/Manager: Non-null strings for empty strings
After #4724, empty strings would result in nullptrs being stored in the
threading::Value's string_val.data field instead of a valid pointer to
an empty strings. This upsets UBSAN's nonnull check for memcpy()
[01:29:45.807] ../../src/SerializationFormat.cc:80:33: runtime error: null pointer passed as argument 2, which is declared to never be null
[01:29:45.807] /usr/include/string.h:44:28: note: nonnull attribute specified here
[01:29:45.807] #0 0x5b2e9c933a3f in zeek::detail::SerializationFormat::WriteData(void const*, unsigned long) /zeek/build/src/../../src/SerializationFormat.cc:80:5
[01:29:45.807] #1 0x5b2e9c935184 in zeek::detail::BinarySerializationFormat::Write(char const*, int, char const*) /zeek/build/src/../../src/SerializationFormat.cc:371:40
Continue to allocate the empty string for now as a fix.
* 'master' of https://github.com/blightzero/zeek:
Changed behavior of var-extraction-uri.zeek from policy/protocol/http to extract only the URI parameter names. Do not include the path in the first parameter name. Only extract uri vars if parameters actually exist.
Previously, Zeek treated the receipt of `AuthenticationOk` as a
successful login. However, according to the PostgreSQL
Frontend/Backend Protocol, the startup phase is not complete until
the server sends `ReadyForQuery`. It is still possible for the server
to emit an `ErrorResponse` (e.g. ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION)
after `AuthenticationOk` but before `ReadyForQuery`.
This change updates the PostgreSQL analyzer to defer reporting login
success until `ReadyForQuery` is observed. This prevents false
positives in cases where authentication succeeds but session startup
fails.
* origin/topic/awelzel/4754-double-wrapped-broker-data-records:
cluster/serializer/broker: Do not special case Broker::Data anymore
broker/Data: Support unwrapping Broker::Data records
The previous approach ignored the fact that nested / inner values might
also be Broker::Data values. I'm not super sure about the validity of
the test, because it's essentially demonstrating any-nesting, but
it's not leading to extra Broker::Data encoding.
Calling val_to_data() on a Broker::Data ends up wrapping the
Broker::Data record instead of using the contained broker::value
directly.
Seems this should be the default behavior and wonder if the flag
even makes sense, but for a 8.0 backport that seems more reasonable.
* origin/topic/timw/move-submodules-to-main-repo:
Fix some clang-tidy findings in generated BIF code
Fix clang-tidy and pre-commit warnings for gen-zam code files
Move gen-zam code into the main Zeek repository
Move zeek-af_packet-plugin code into the main Zeek repository
Move the bifcl code into the main Zeek repository
Fix clang-tidy findings in the binpac lib code
Add copyright headers to all of the binpac source files
Move binpac code into the main Zeek repository
Parameters relied on is_record for a couple of validations, but they are
not records and should not be treated as such. This way we can validate
&optional better.
There was some confusing behavior with &optional and locals, so this
should get rid of that by making it an error. However, there is a case
where function parameters are still allowed to have &optional - this is
because there are checks for &default in parameters as well.
* origin/topic/awelzel/docker-trixie:
ci: Run zeekctl and builtin tasks with Debian 13, too
ci: Prepend timestamps to output
ci: Enable Spicy for arm_debian13
ci: Add Debian 13.0 (trixie)
docker: Bump to debian:trixie-slim
