* topic/christian/gh-2761-default-localnets:
Update NEWS to cover new Site::local_nets behavior.
Bump external testsuites to reflect updated baselines
Add btests for new Site::local_nets behavior
Update plugins.hooks baseline to reflect added config framework activity
Update scripts.policy.misc.dump-events baseline
Update btest baselines to reflect the use of local address ranges.
Tighten local-nets filtering in the logging framework's path-func-column-demote test
Fix scripts.policy.frameworks.intel.removal test given address locality info
Treat private address space as site-local by default
Provide a mechanism to suppress logging of internal config framework activity
This test used `Site::is_local_addr()` as part of a filtering criterion, perhaps
unintentionally. The fact that it applied to all tested addresses kept a Zeek
process from exiting, failing the test. It also doesn't need to prioritize its
zeek_init() handler.
This makes Site::private_address_space work like a subset of Site::local_nets,
to match many user's intuition of how we should treat site locality out of the
box. As config options, changes/redefs to Site::private_address_space propagate
to Site::local_nets, while changes to the latter don't affect the former.
A new global bit `Site::private_address_space_is_local` controls the behavior.
It defaults to true, and redefing to false brings back the original behavior.
OpenSSL 3.1 switched from outputting UNDEF to not giving a short name in
this case. Luckily this only requires a tiny test change.
We might consider pulling this into older versions, for ease of CI
testing.
Fixes GH-2869
* 'dnssec-flag-parse' of github.com:micrictor/zeek-codespace:
Update external testing commit hash for DNS flag changes
Parse DNSSEC AD and CD bits
Updated dump-events baseline which seemed unrelated.
Parse authentic data (AD) and checking disabled (CD) bits according to
RFC 2535. Leaves the Z field as-is, in case users are already handling
this elsewhere and depend on the value being the integer for all 3 bits.
https://www.rfc-editor.org/rfc/rfc2535#section-6.1Fixes#2672
This was exposed by OSS-Fuzz after the HTTP/0.9 changes in zeek/zeek#2851:
We do not check the result of parsing the from and last bytes of a
Content-Range header and would reference uninitialized values on the stack
if these were not valid.
This doesn't seem as bad as it sounds outside of yielding non-sensible values:
If the result was negative, we weird/bailed. If the result was positive, we
already had to treat it with suspicion anyway and the SetPlainDelivery()
logic accounts for that.
* origin/topic/timw/coverity-issues:
dlclose() handle if the library loaded wasn't a plugin
Fix uninitialized variables in Ascii writer
Fix use-after-move bug in Scope constructor
Add missing field initializations for ConnTuple
Fix possible resource leak in analyzer unit tests
OSS-Fuzz tickled an assert when sending a HTTP response before a HTTP/0.9
request. Avoid this by resetting reply_message upon seeing a HTTP/0.9 request.
PCAP was generated artificially: Server sending a reply providing a
Content-Length. Because HTTP/0.9 processing would remove the ContentLine
support analyzer, more data was delivered to the HTTP_Message than
expected, triggering an assert.
This is a follow-up for zeek/zeek#2851.
* origin/topic/timw/2845-http-09:
Add weird for unknown HTTP/0.9 request method
Special case HTTP 0.9 early on
Remove a couple unnecessary break statements
Mostly, treat HTTP0.9 completely separate. Because we're doing raw
delivery of a body directly, fake enough (connection_close=1, and finish
headers manually) so that the MIME infrastructure thinks it is seeing a
body.
This deals better with the body due to accounting for the first line. Also
it avoids the content line analyzer to strip CRLF/LF and the analyzer
then adding CRLF unconditionally by fully bypassing the content line
analyzer.
Concretely, the vlan-mpls test case contains a HTTP response with LF only,
but the previous implementation would use CRLF, accounting for two many bytes.
Same for the http.no-version test which would previously report a body
length of 280 and now is at 323 (which agrees with wireshark).
Further, the mime_type detection for the http-09 test case works because
it's now seeing the full body.
Drawback: We don't extract headers when a server actually replies with
a HTTP/1.1 message, but grrr, something needs to give I guess.
This reworks 2aec7640dd (zeek/zeek#2039) to
avoid calling ExtractNextPacketInternal() within GetNextTimeout() for
the non-pseudo-realtime case. Also relates to zeek/zeek#2842.
The intention of the referenced change was to avoid a 0.00002 timeout when
a non-selectable packet source has more packets queued. This was implemented
by checking for a new packet within GetNextTimeout().
The proposed change switches to an predictive approach: Use the result of
the previous ExtractNextPacket() call (stored as had_packet) as an indication
whether more packets are to be expected.
Calling ExtractNextPacketInternal() within GetNextTimeout() may cause
surprising behavior as some packet source may block [1] or spent a significant
amount of time (e.g. applying BPF filters [2]) within ExtractNextPacket().
The result of GetNextTimeout() should be available immediately as guidance
for the main-loop and the actual work should happen within the ->Process()
method.
This change also attempts to separate the pseudo-realtime logic from the
non-pseudo-realtime in an attempt show pseudo-realtime as special.
[1] 00c4d657e0/src/Napatech.cc (L116)
[2] 58b25c8eba/src/Myricom.cc (L250)
It wasn't possible from script land to determine the total size
of the cache table held by the DNS_Mgr. Add the total and also
also the TEXT entries count.
