* origin/topic/awelzel/smtp-bdat-follow-up-2:
SMTP/BDAT: Use strtoull and bail on UULONG_MAX values
SMTP/BDAT: Fix int/int64_t/uint64_t confusion
SMTP: Reject BDAT chunks larger than int64_t's max value
* topic/christian/more-feature-tests:
Default to setting ZEEK_HAVE_JAVASCRIPT=no in CMakeLists.txt
Show --disable-javascript in `configure --help`
Show AF_PACKET support status in cmake output, and sort features
Add feature tests for AF_PACKET, GeoIP, and JavaScript to zeek-config
The BDAT analyzer should be supporting uint64_t sized chunks reasonably well,
but the ContentLine analyzer does not, And also, I totally got types for
RemainingChunkSize() and in DeliverStream() wrong, resulting in overflows
and segfaults when very large chunk sizes were used.
Tickled by OSS-Fuzz. Actually running the fuzzer locally only took a
few minutes to find the crash, too. Embarrassing.
The Spicy/HILTI runtime libraries are modelled as object libraries and
linked into the `spicy` and `hilti` libraries. These libraries are then
linked into `zeek_objs` which is another object library linked into the
`zeek` executable (target `zeek_exe`). On some platforms this transitive
link of object libraries is broken with `--binary-package` which causes
creation of static archives, even with our minimum required CMake
version which already contains many fixes for object libraries.
With this patch we now explicitly linked the Spicy/HILTI runtime
libraries into `zeek_exe`.
Closes#3177.
This still overrides it as appropriate when building with JS support, but shows
"JavaScript: no" in the configure output also when using
--disable-javascript, where it previously showed no output.
OSS-Fuzz managed to produce a MIME multipart message construction with
thousands of nested entities (or that's what Zeek makes out of it anyhow).
Prevent such deep analysis by capping at a nesting depth of 100,
preventing unnecessary resource usage. A new weird named exceeded_mime_max_depth
is reported when this limit is reached.
This change reduces the runtime of the OSS-Fuzz reproducer from ~45 seconds
to ~2.5 seconds.
The test PCAP was produced from a Python script using the email package
and sending the rendered version via POST to a HTTP server.
Closes#208
OSS-Fuzz found that providing an invalid BDAT line would tickle an
assert in UpdateState(). The BDAT state was never initialized, but
within UpdateState() that was expected.
This also removes the AnalyzerViolation() call for bad BDAT commands
and instead raises a weird. The SMTP analyzer is very lax and not triggering
the violation allows to parse the server's response to such an invalid
command.
PCAP files produced by a custom Python SMTP client against Postfix.
* origin/topic/vern/script-opt-maint.Jan24:
ZAM speedup for constructing empty vectors
fixes for ZAM optimization of "switch" statements
BTests to catch regressions for recent ZAM fixes
"-a zam" BTest baseline update for recent changes
fix for needing to always flush optimization information for identifiers
fix for logic bug in ldap base script
better name for key variable in script optimization
ZAM fix for tracking variable usage
ZAM fixes for "for" loops that are only used to choose an element from a table/set
ZAM fixes for loops indexed with variables not used in the loop body
fix for ZAM location tracking - more extensive changes are pending
fixes for ZAM's special-casing of that "cat" BiF
some fixes for ZAM memory management
streamlining of some script optimization APIs
fixes for initializations of "-O gen-C++" script compilations
script optimization fixes for "concretizing" vector-of-any's
