* origin/topic/robin/gh-3561-forward-to-udp:
Update docs.
Add explicit children life-cycle management method to analyzers.
Spicy: Support UDP in Spicy's `protocol_*` runtime functions.
Add method to analyzer to retrieve direct child by name.
Extend PIA's `FirstPacket` API.
Spicy: Prepare for supporting forwarding to protocols other than TCP.
* origin/topic/christian/fix-zeekygen-crash:
Avoid segfault when generating Zeekygen docs on Zeek-internal identifiers.
Add btest for Zeekygen docs extraction on identifiers defined by the Zeek core.
This extends the ability to feed new payload back into Zeek's analyzer
pipeline from TCP to now also UDP.
Note: We don't extend this further to ICMP because the ICMP analyzer
cannot be dynamically instantiated (Zeek aborts when trying so). As
ICMP isn't very interesting from use-case perspective anyways, that
seems fine.
Closes#3561.
`FirstPacket()` so far supported only TCP. To extend this to UDP, we
move the method into the PIA base class; give it a protocol parameter
for the case that there's no actual packet is available; and add the
ability to create fake UDP packets as well, not just TCP.
This whole thing is pretty ugly to begin with, and this doesn't make
it nicer, but we need this extension that so we can feed UDP data into
the signature engine that's tunneled over other protocols. Without the
fake packets, DPD signatures in particular wouldn't have anything to
match on.
So far the Spicy runtime supported forwarding data into other
analyzers only for TCP analyzers. This puts branching logic in place
that let the relevant runtime functions dispatch differently based on
the target transport-layer protocol. We don't implement anything else
than TCP yet; that will come next.
Along with the internal changes, this also updates the user-visible
runtime function to pass protocol information in. For now, this
likewise remains limited to TCP. The function signatures are chosen so
that they stay backwards-compatible to previous Spicy version. In
particular, they default to TCP where not otherwise specified.
* origin/topic/robin/gh-3573-replaces-cleanup:
Fix packet analyzer replacement.
Spicy: Wenn replacing an analyzer add a component mapping.
Add component API to transparently remap one component to another one.
Move enabled/disabled functionality from analyzers into `Component` base class API.
This uses the new API to replace components internally.
With these changes in place, replacing protocol analyzers now don't
need to register their ports anymore if they match what the original
analyzer was using (because the old one's registrations will map
over).
Packet analyzer replacement doesn't quite work yet but will be fixed
in next commit.
Closes#3573.
When a specific component is requested through its tag or name, one
can now have the component manager transparently return a different
one that has been registered to replace the original one. We limit
this to disabled components to avoid unnecessary confusion. That also
means that remappings are currently only supported for analyzers
(because other types of components cannot be disabled for now, per the
previous change).
The different analyzers types all had their own methods for
enabling/disabling their availability. This change abstracts that into
a new API inside their base class (`plugin::Component`) so that they
can be toggled in a unified way.
In principle, other types of components could/should use this as well
now, so that, e.g., an input reader's availability could be toggled at
runtime. The code doesn't make that broader change for now because it
would requires a series of changes wherever these other component
types are being used. However, that means that one now could try
toggling some other component through the new API without that having
any effect. To catch that, there's a runtime check in place that turns
any such attempt into an internal error.
Like traditional file analyzers, we now query Zeek's
`get_file_handle()` event for handles when a connection begins
analyzing an embedded file. That means that Spicy-side protocol
analyzers that are forwarding data into file analysis now need to call
Zeek's `Files::register_protocol()` and provide a callback for
computing file handles. If that's missing, Zeek will now issue a
warning. This aligns with the requirements Zeek's traditional protocol
analyzers. (If the EVT file defines a protocol analyzer to `replace`
an existing one, that one's `register_protocol()` will be consulted.)
Because Zeek's `get_file_handle()` event requires a current
connection, if a Spicy file analyzer isn't directly part of a
connection context (e.g., with nested files), we continue to use
hardcoded, built-in file handle. Scriptland won't be consulted in
that case, just like before.
Closes#3440.
Identifiers that Zeek generates explicitly in-core for example during component management
("Analyzer::ANALYZER_FOO", "Input::READER_FOO", etc), aren't associated with any
scripts and would lead to nullpointer derefs when trying to identify
modification time.
This fix returns a zero timestamp in such cases, ensuring it never triggers docs
refreshes. We do the same e.g. in PackageInfo instances.
* origin/topic/vern/script-opt.May24:
factored BTest constants into globals to prevent premature ZAM optimization when testing
addressed minor issues flagged by Coverity
Relying only on the IP-header-provided length could violate buffer boundaries in
the endpoints' rule matching. This change mirrors what we do in UDP and TCP.
Resolves#3671
