Also set some convenience variables that mimic what a FindBinPAC
module would set. These could be used by a superproject that
wants to decide whether to use an existing BinPAC installation
or (re)build from source.
- Moved find_package() calls up to top directory so failure can occur
right away if any dependencies are missing
- Got rid of a bunch of header checks and preprocessor definitions that
aren't ever used; not sure why I had them there in the first place
- Renamed VERSION preprocessor definition to not conflict with Bro's.
- Removed check for HAVE_CONFIG_H; config.h will always be generated in the
binpac build directory, but if a parent directory has generated a config.h
and added that to compiler include search paths via include_directories(),
then that one should be used -- include_directories() appends paths by
default and the parent CMakeLists.txt will have called it first.
* 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.
