The Python docker-compose executable in the docker_builder image is not
functional anymore (TypeError: kwargs_from_env() got an unexpected
keyword argument 'ssl_version').
docker-compose v1 has been sun-setted for quite some time. Do the
minimal to switch to docker compose v2.
* origin/topic/vern/script-opt-maint.Mar24:
AST location fixes for -O gen-C++
script optimization support for clearing tables/vectors using "delete"
fix for ZAM printing of instructions that modify slots other than slot 1
fixed bug where appending an empty vector to a vector-of-vector's had no effect
@vpax reported surprising behavior when working with "void values".
While these are not exposed to script land, plumb the places he
pointed out are causing confusing behavior.
Closes#3640.
Since 81a9745fb3, the assert condition is
evaluated twice. This leads to unexpected behavior when cond has a side
effect like publishing a message or creating a log stream or filter.
Found while using the following in ad-hoc testing code and wondering
why two messages were published.
assert publish(Cluster::worker_topic, hello, "abc")
When creating RE_Matcher instances at runtime and verifying the pattern
compiles via Compile(), the syntax_error flag wasn't respected and
Compile() would return true even for some invalid regular expressions.
For example, compiling /a{1,b}/, Compile() would return true even though
it produced a reporter error while parsing complaining about b not
being valid.
This patch improves the error handling, so that calling Compile() returns
false whenever zeek::detail::synerr() was called while a pattern was
parsed. The use-case is creation of patterns at runtime based on
JavaScript strings. These might be entered or received at runtime via
an API. This change allows to be a bit more robust to detect invalid
input and raising exceptions to notify the user.
This also move syntax_error and csize out of global scope.
If RE_Matcher was to be used as an actual API, we likely should squelch
the reporter errors and mark it as not thread safe, but this is a small
step forward.
0a89ca6 doc: Expand zeek.as() description and add an example
7e814d7 Types: Implement basic pattern support
43df9d2 Update docs to provide example of shared Node.js openSSL configuration
3bf2ea5 lsan suppressions: Add some for 21.11
640affa zeek.global_vars: Remove leftover internal field usage
3ee53c7 zeek.global_vars: Implement setter
8144061 zeek.as: Support more Zeek types
b453483 zeek.as: Fix crash for non-atomic types
Zeekygen implements its own make-style update logic to prevent
re-creation of files that have not changed. To fulfill this, we
currently encode the current time into spicyz generated .cc files.
This degrades ccache efficiency for built-in analyzers and also
for all .evt files compiled during testing. Switch SpicyModuleInfo
to return current time instead. This results in the re-generation
of documentation files unconditionally when running Zeekygen, but
that seems more acceptable IMO.
Generally wonder if Zeekygen should produce output unconditionally
and if we need to clobber prevention, compare with the content of
the existing file.
Closes#3619
* origin/topic/awelzel/move-iso-9660-sig-to-policy:
signatures/iso-9660: Add \x01 suffix to CD001
test-all-policy: Do not load iso-9660.zeek
signatures: Move ISO 9660 signature to policy
Changing the default_file_bof_buffer_size has subtle impact on
MIME type detection and changed the zeek-testing baseline. Do
not load this new script via test-all-policy to avoid this.
The new test was mainly an aid to understand what is actually going on.
In short, if default_file_bof_buffer_size is larger than the file MIME
detection only runs when the buffer is full, or when the file is removed.
When a file transfer happens over multiple HTTP connections, only
some or one of the http.log entries will have a proper response MIME type.
PCAP extracted from 2009-M57-day11-18.trace.gz.
The previous "fix" caused significant performance degradation without
the signature ever having a chance to trigger. Moving it to policy
seems the best compromise, the alternative being outright removing it.
It seems that Zeek's version number and string only need to be
available at runtime, so this change removes it from spicyz/configh.in
to avoid needlessly busting ccache for the src/spicyz tree for on a
Zeek version bump.
Closes#3139.
