This mimics how the Teredo analyzer is already doing it, including
sending a weird if the session is invalid and bailing out if the
protocol was already violated.
An unnecessary overhead of the Hash() method was uncovered for DEBUG builds
due to computing a description of every HashKey() even when the DBG_HASHKEY
stream is not enabled. Squelch it.
This adds a new utility called ci/collect-repo-info.py to produce a JSON
document that is then baked into the Zeek executable file. Further, when
creating a tarball via `make dist`, put a top-level repo-info.json file
in place that is picked when no .git directory exists.
Closes#1405
* Add ci/find-current-version.sh to figure out versions of lts and
feature branch based on repository state.
* Do not use ZEEK_IMAGE_REPO for the local images that
are expected to exist.
* Only use IMAGE_NAME/IMAGE_TAG instead of the ARCH and MANIFEST
versions that contained the very same values
* Support and push additional tags
In addition to the lts and feature tags, also push the base version
tags. 5.0 or 5.1 such that someone pulling zeek/zeek:5.0 will get
the most recent available 5.0 patch release.
* origin/topic/awelzel/get-file-handle-fallback-and-no-new-event-when-fuzzing:
krb/smb2_krb_nokeytab: Register get_file_handle() to avoid warnings
fuzzer-setup: Do not always generate new_event
EventHandler: Support unsetting generate_always
files/main: No empty file_ids
When an analyzer calls DataIn(), there's a costly callback construct
going through the event queue. If an analyzer does not have a
get_file_handle() handler installed, the produced file_id would
end up empty and ignored. Consequently, the get_file_handle() callback
was invoked for every new DataIn() invocations.
This is surprising and costly. Log a warning when this happens and
instead set a generically generated file handle value instead to
prevent the repeated get_file_handle() invocations.
We previously used the Spicy plugin's `Spicy::available` to test for
Spicy support. However, having Spicy support does not necessarily mean that we
have built Zeek with its in-tree Spicy analyzers: the Spicy plugin
could have been pulled in from external. The new BIF now reliably
tells us whether the Spicy analyzers are available; its result
corresponds to what `zeek-config --have-spicy-analyzers` returns as
well.
We also move the two current checks over to use this BIF.
(Note: I refrained from renaming the CMake-side `USE_SPICY_ANALYERS`
to `HAVE_SPICY_ANALYZERS`. We should do this eventually for
consistency, but I didn't want to make more changes than necessary
right now.)
* origin/topic/awelzel/arm64-container-follow-ups-2:
Bump private testsuite for char handling fixes
Base64: report byte as positive integer
netbios_decode: use unsigned char for result
analyzer/http: Do not assume char is signed
cirrus: Run tests in a Debian 11 container, too
