@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.
A user reported being confused about the fuid association of subsequent
FTP commands when a data transfer has completed. It seems reasonable to
unset fuid upon logging a FTP command which had a fuid.
The current behavior results in the PORT or PASV commands after a RETR or STOR
to have the fuid of the prior file transfer. Similarly, any CWD or DEL commands
following a file transfer will unnecessarily be logged with the fuid of the
prior file transfer.
This tickles the baselines for the private testing PCAP a lot, primarily
because there data connections in that pcap are never established properly.
E.g, the fuids FzDzid1Dxm9srVKHXf and FEfYX73q5C6GEQZXX9 have been re-used
for multiple commands.
This may look like we're losing information, but the fuids vanishing
in the normal btests belong to a LIST command that isn't logged by
default into ftp.log. If it was, the fuid would be attached to it.
