Add new hook HookLoadFileExtended that allows plugins to supply Zeek script code to parse.

The new hooks works similar to the existing `HookLoadFile` but,
additionally, allows the plugin to return a string that contains the
code to be used for the file being loaded. If the plugin does so, the
content of any actual file on disk will be ignored (in fact, there
doesn't even need to be a file on disk in that case). This works for
both Zeek scripts and signatures.

There's a new test that covers the new functionality, testing loading
both scripts and signatures from memory. I also manually tested that the
debugger integration works, but I don't see much of a way to add a
regression test for that part.

We keep the existing hook as well for backwards compatibility. We could
decide to deprecate it, but not sure that buys us much, so left that
out.

Closes #1757.
This commit is contained in:
Robin Sommer 2021-09-24 12:50:27 +02:00
parent 1efaf8d7a4
commit 34eaf42b92
21 changed files with 1525 additions and 92 deletions

View file

@ -245,6 +245,32 @@ public:
virtual int HookLoadFile(const Plugin::LoadType type, const std::string& file,
const std::string& resolved);
/**
* Hook that gives plugins a chance to take over loading an input file,
* including replacing the file's content. This method must be called
* between InitPreScript() and InitPostScript() for each input file Bro is
* about to load, either given on the command line or via @load script
* directives. The hook can take over the file, in which case Bro must not
* further process it otherwise; or provide its content, in which case Bro
* must use that and ignore the original file.
*
* @return tuple where the first element is 1 if a plugin took over the
* file; 0 if a plugin took over the file but had trouble loading it; and
* -1 if no plugin was interested in the file at all.
*
* If the plugins takes over by returning 1, there are two cases: if the
* second tuple element remains unset, the plugin handled the loading
* completely internally; the caller must not process it any further.
* Alternatively, the plugin may optionally return the acutal content to
* use for the file as a string through the tuple's second element. If so,
* the caller must ignore the file on disk and use that provided content
* instead (including when there's actually no physical file in place on
* disk at all).
*/
virtual std::pair<int, std::optional<std::string>>
HookLoadFileExtended(const Plugin::LoadType type, const std::string& file,
const std::string& resolved);
/**
* Hook that filters calls to a script function/event/hook.
*