Before, that API was part of the analyzers themselves, which meant we
couldn't disable a packet analyzer before it had been instantiated.
That's different from protocol/file analyzers, where we disable them
through the corresponding component. The lack of the component-side
API prevented Spicy from replacing packet analyzers at startup.
The reason we had put this into analyzer originally was performance so
that we don't need a component lookup for every packet. This change
keeps that optimization by caching the on/off state in the analyzer
itself as well, but now with the component being the one controlling
it.
There was a check generating an internal warning if a new packet
analyzer mapping overwrote an existing one. However, replacing
an existing analyzer with a new one seems a legitimate use case (and
will be supported by Spicy soon). So removing that warning.
This uses the v3 json as a source for the first time. The test needed
some updating because Google removed a couple more logs - in the future
this should hopefully not be neccessary anymore because I think v3
should retain all logs.
In theory this might be neat in 5.1.
* 'topic/jgras/dependabot-updates' of https://github.com/J-Gras/zeek:
Bump actions/checkout from 2 to 3
Bump actions/upload-artifact from 2 to 3
Bump dawidd6/action-send-mail from 3.6.1 to 3.7.0
Bump actions/setup-python from 2 to 4
Bump docker/login-action from 1 to 2
* origin/topic/vern/CPP-global-init:
updates to -O C++ user and maintenance documentation
use dynamic rather than static initialization of globals for scripts compiled to C++
safety checking for initializing scripts compiled to C++
fixes for initializing scripts compiled to C++
restructured tracking of initializations of globals for script compilation
This allows to enable/disable file analyzers through the same interfaces
as packet and protocol analyzers, specifically Analyzer::disable_analyzer
could be interesting.
This adds machinery to the packet_analysis manager for disabling
and enabling packet analyzers and implements two low-level bifs
to use it.
Extend Analyzer::enable_analyzer() and Analyzer::disable_analyzer()
to transparently work with packet analyzers, too. This also allows
to add packet analyzers to Analyzer::disabled_analyzers.
Passing nullptr sessions to AnalyzerConfirmation and AnalyzerViolation
of protocol analyzers previously blew up - protect from that.
Related to zeek/spicy-plugin#133.
Add a test parsing a malformed PE file showing that analyzer_violation_info
is raised with the fa_file object set.
It could be interesting to pass through an optional connection if one
exists, but access is provided through f$conns, too.
Introduce two new events for analyzer confirmation and analyzer violation
reporting. The current analyzer_confirmation and analyzer_violation
events assume connection objects and analyzer ids are available which
is not always the case. We're already passing aid=0 for packet analyzers
and there's not currently a way to report violations from file analyzers
using analyzer_violation, for example.
These new events use an extensible Info record approach so that additional
(optional) information can be added later without changing the signature.
It would allow for per analyzer extensions to the info records to pass
analyzer specific info to script land. It's not clear that this would be
a good idea, however.
The previous analyzer_confirmation and analyzer_violation events
continue to exist, but are deprecated and will be removed with Zeek 6.1.
