The Spicy analyzer is added as a child analyzer when enabled and the
WebSocket.cc logic dispatches between the BinPac and Spicy version.
It substantially slower when tested against a somewhat artificial
2.4GB PCAP. The first flamegraph indicates that the unmask() function
stands out with 35% of all samples, and above it shared_ptr samples.
* origin/topic/johanna/netcontrol-updates:
Netcontrol: add rule_added_policy
Netcontrol: more logging in catch-and-release
Netcontrol: allow supplying explicit name to Debug plugin
* origin/topic/christian/cluster-pool-nodetype-default:
Do not default PoolSpec topics to the empty string.
Do not default to proxy nodes in Broker::PoolSpec
* origin/topic/timw/fix-alpine-ci-image:
Add missing include for int32_t in DebugCmds.h
CI: Remove emacs backup file of fedora-38 Dockerfile
CI: Fix building of alpine image with regards to python packages
This requires pool creation to spell out a spec explicitly, which the only code
using these types already does. There's no reason for pools to automatically
refer to proxies.
rule_added_policy allows the modification of rules just after they have
been added. This allows the implementation of some more complex features
- like changing rule states depending on insertion in other plugins.
Catch-and-release logs now include the plugin that is responsible for an
action. Furthermore, the catch-and-release log also includes instances
where a rule already existed, and where an error occurred during an
operation.
This change extends the arguments of NetControl::create_debug, and
allows the specification of an optional name argument, which can be used
instead of the default-generated name.
This is helpful when one wants to attach several plugins to verify
behavior in those cases.
* origin/topic/timw/update-c-ares:
Configure c-ares before libkqueue
Update 3rdparty submodule to update sqlite to 3.45.0
Upgrade rapidjson to current upstream master
Upgrade c-ares to 1.26.0
On platforms without a native libkqueue, c-ares is using the existing
value for HAVE_KQUEUE that was set during the libkqueue setup. We don't
pass the libkqueue information down to the c-ares cmake run so it won't
have the paths or library when it builds.
Seem reasonable give we log the server SCID. Interestingly, the Chromium
examples actually have zero length (empty) source connection IDs. I wonder
if that's part of their "protocol ossification avoidance" effort.
The original logic stopped decrypting any INITIAL packets after the
first. The Firefox/cloudflare pcaps actually show that the server
replies with a QUIC INITAL packet containing just ACK frames and no
CRYPTO frames. Only the second QUIC INITIAL packet from the server
then contains the CRYPTO frames.
There's no good reason to stop decryption attempts, either we succeed
down the road and then stop, or we fail and raise analyzer violations.
* topic/christian/mmdb-fix:
Move GeoIP availability test in btests to `zeek-config --have-geoip`
Fix MMDB::Lookup() to check result status correctly
Add btest for succeeding/failing IPv4/IPv6 lookups
Add an IPv6 range to the test MMDB DBs
There's something wrong with chocolatey's OpenSSL 3.2.0 package that
causes cmake to not be able to find libcrypto even though it's clearly
in the directory. Pinning to 3.1.1 fixes the build issue.
