When using --include-plugins with plugins that depend other libraries
using zeek_plugin_link_library(), these libraries were stashed into
bro_SUBDIR_LIBS that is used in add_executable(). However, that does not
work for shared libraries.
Explicitly track library dependencies in bro_PLUGIN_LINK_LIBS now and
use target_link_libraries() with Zeek (there's a change in cmake to
make zeek_plugin_link_library() populate bro_PLUGIN_LINK_LIBS instead).
Currently, zeekdeps needs to come after bro_PLUGIN_LINK_LIBS due to how
spicy-plugin (and other external plugins) fiddle with zeekdeps in order
to stash dependencies into the PARENT_SCOPE.
bro_PLUGIN_LINK_LIBS will continue to work with static libraries.
The failure occurred when attempting to include bro-http2 [1].
Fixes#2483
[1] https://github.com/MITRECND/bro-http2
Script and BIF functions with a single any parameter are excluded from
type checking regarding arguments. This makes it possible to call a
ScriptFunc with more arguments than it actually has parameters and frame
space for, causing heap-buffer-overflows.
This change runtime checks expected parameters and provided arguments
and short-circuits execution as well as logging runtime expression errors.
Fixes#2446
Seemed easiest to do it via the traversal infrastructure as we do not
otherwise track enough context/scope when instantiating break or next
statements.
Might be worth moving this out of src/parse.y, but didn't exactly know
where. Or maybe we wait until there's more such trivial validations
popping up
Fixes#2440
spicy-plugin-1.4.0 changes behavior, so it is not backwards-compatible
with the spicy-plugin-1.3 series. This patch should not be backported to
LTS release branches.
Using positional and vararg arguments for BIFs, it's not possible to do
proper runtime type checking on them as discussed in #2425. The bifcl produced
code unconditionally attempts to convert the positional arguments to StringVals,
but nothing ever type checks them. Instead of improving the vararg support in
Zeek script and bifcl, align cat_sep() with fmt() in making it fully vararg
and do implement type checks by hand.
With this change, passing wrong types for the separator and default argument
isn't a fatal error anymore and the error messages are also more descriptive.
It's a bit of a crutch working around varargs limitations.
Fixes#2425
One more from @stevesmoot. The record_fields() BIF produced "enum" as
type_name for fields of type enum.
Extend container_type_name() to append the actual name of the enum.
This is changing the format and may break consumers, but those are
likely in a category that are happy to adapt. Not having the actual
enum name available wasn't very helpful.
We could alternatively render only the actual type_name without the
prefixed "enum", but that isn't how it's done for record types currently
and it would make it more difficult to decide which subsequent BIFs to
use for further introspection, like enum_names().
This started with reverting commit 52cd02173d
and then rewriting it to be per handler rather than handler identifier
and adding support for hooks as well as adding implicit module groups.
This seems to be an age-old bug. Reported by mchen on discourse [1].
The TCPSessionAdapter decides in AddExtraAnalyzers() whether to enable
reassembly or not. When dpd_reassemble_first_packets is F, this boils down to
! GetChildren().empty(). The intention being that if any analyzers have been
added to the connection based on known ports, reassembly is to be enabled.
However, GetChildren() does not take into account new_children and so
! GetChildren().empty() is always false here and reassembly solely
based on dpd_reassemble_first_packets=F (or the tcp_content... options).
Ouch.
Call AppendNewChildren() before AddExtraAnalyzers() as a fix. Without this,
the new test does not produce an http.log and service "http" isn't in conn.log.
[1] https://community.zeek.org/t/how-to-activate-an-application-layer-analyzer-when-signature-dpd-reassemble-first-packets-is-off/6763
The controller now listens on an additional port, defaulting to 2149, for Broker
connections via websockets. Configuration works as for the existing traditional
Broker port (2150), via ZEEK_CONTROLLER_WEBSOCKET_ADDR and
ZEEK_CONTROLLER_WEBSOCKET_PORT environment variables, as well as corresponding
redef'able constants.
To disable the websockets feature, leave ZEEK_CONTROLLER_WEBSOCKET_PORT unset
and redefine Management::Controller::default_port_websocket to 0/unknown.
Mostly: Do not instantiate variables within for loops and allow
reusing differently typed blanks which previously wasn't possible.
This may be missing some corner-cases, but the added tests seem
to work as expected and nothing else fell apart it seems.
The Coverity build used an external CAF setup because the bundled build used to
cause internal errors in Coverity's tooling. zeek/broker#285 causes a problem
with the external CAF setup, plus Coverity now looks happy with the usual
bundled build, so this commit simply drops the external CAF approach.
* origin/topic/timw/2132-bpf-filtering-error-messages:
Remove cmake tests for LIBPCAP_PCAP_COMPILE_NOPCAP_HAS_ERROR_PARAMETER
Rework the non-pcap version of BPF_Program::Compile
Add btest that exercises the pcap filter warnings
Update docs submodule
Restore reporting messages for pcap filter issues
Add column to packet_filter.log for failure reason
Store error message from BPF compilation
Minor cleanup in BPF filtering code
In his ZeekWeek 2022 presentation, @stevesmoot mentioned that he had a
difficult time looking up enum names when all he had was a string
naming the type.
Add support to enum_names() to transparently lookup the type if a string
is provided. This is similar in how record_fields() behaves when being
passed a string.
