With a bit of tweaking in the JavaScript plugin to support opaque types, this
will allow the delay functionality to work there, too.
Making the LogDelayToken an actual opaque seems reasonable, too. It's not
supposed to be user inspected.
This is a verbose, opinionated and fairly restrictive version of the log delay idea.
Main drivers are explicitly, foot-gun-avoidance and implementation simplicity.
Calling the new Log::delay() function is only allowed within the execution
of a Log::log_stream_policy() hook for the currently active log write.
Conceptually, the delay is placed between the execution of the global stream
policy hook and the individual filter policy hooks. A post delay callback
can be registered with every Log::delay() invocation. Post delay callbacks
can (1) modify a log record as they see fit, (2) veto the forwarding of the
log record to the log filters and (3) extend the delay duration by calling
Log::delay() again. The last point allows to delay a record by an indefinite
amount of time, rather than a fixed maximum amount. This should be rare and
is therefore explicit.
Log::delay() increases an internal reference count and returns an opaque
token value to be passed to Log::delay_finish() to release a delay reference.
Once all references are released, the record is forwarded to all filters
attached to a stream when the delay completes.
This functionality separates Log::log_stream_policy() and individual filter
policy hooks. One consequence is that a common use-case of filter policy hooks,
removing unproductive log records, may run after a record was delayed. Users
can lift their filtering logic to the stream level (or replicate the condition
before the delay decision). The main motivation here is that deciding on a
stream-level delay in per-filter hooks is too late. Attaching multiple filters
to a stream can additionally result in hard to understand behavior.
On the flip side, filter policy hooks are guaranteed to run after the delay
and can be used for further mangling or filtering of a delayed record.
If we delay in the stream policy hook, we'll need to resume writing
to the attached filters later on. Prepare for that by splitting out
the filter processing.
Contains the following fixes:
2da4abe Types: Add support for opaque types
1f1093f Types: Cast internal field to v8::Value
67e225c Plugin: Avoid creating Exprs at runtime
* origin/topic/timw/copy-instead-of-move:
Add some uses of std::move in constructors and simple functions for pass-by-value arguments
Avoid creating a few temporary values to avoid copy operations
Change function return types to more concise types where possible
Update cipher consts.
Furthermore some past updates have been applied to scriptland, but it
was not considered that some of these also have to be applied to binpac
code, to be able to correcly parse the ServerKeyExchange message.
(As a side-note - this was discovered due to a test discrepancy with the
Spicy parser)
* origin/master: (73 commits)
Spicy: allow providing file id in zeek::file_begin
Spicy: allow providing file id in zeek::file_begin
Update doc submodule [nomail] [skip ci]
Spicy: allow providing file id in zeek::file_begin
Spicy: allow providing file id in zeek::file_begin
Bump cmake submodule for INCLUDE_DIRS fix
Update doc submodule [nomail] [skip ci]
Integrate review feedback
Add jq to final.Dockerfile
TableVal: Replace raw subnets/pattern_matcher with unique_ptr
TablePatternMatcher: Drop Insert()/Remove(), use Clear()
TableType: Simplify and inline Is...Index tests
NEWS: Add small table[pattern] section
Expr/Val: Add support for in set[pattern]
zeek.bif: Implement table_pattern_matcher_stats() bif for introspection
DFA: Extract inner Stats struct from DFA_State_Cache
Expr: Implement string in table[pattern] of X
RE: Remove RE_DisjunctiveMatcher and re-use MatchAll()
TablePatternMatcher: Use const StringValPtr& instead of const StringVal*
Val: Move TablePatternMatcher into detail namespace
...
Allow spicy parsers to generate their own file IDs and provide them to
Zeek. This duplicates functionality that is currently possible (and
used) by some binpac-based analyzers. One example for an analyzer
creating its own file IDs is the SSL analyzer.
* origin/topic/neverlord/avoid-openssl-header-deps:
Integrate review feedback
Avoid OpenSSL header dependencies
Added NEWS during merge and removed never set OPENSSL_INCLUDE_DIR reference
in main CMakeLists.txt.
* origin/topic/awelzel/pattern-tables-reuse-compile-set:
TableVal: Replace raw subnets/pattern_matcher with unique_ptr
TablePatternMatcher: Drop Insert()/Remove(), use Clear()
TableType: Simplify and inline Is...Index tests
NEWS: Add small table[pattern] section
Expr/Val: Add support for in set[pattern]
zeek.bif: Implement table_pattern_matcher_stats() bif for introspection
DFA: Extract inner Stats struct from DFA_State_Cache
Expr: Implement string in table[pattern] of X
RE: Remove RE_DisjunctiveMatcher and re-use MatchAll()
TablePatternMatcher: Use const StringValPtr& instead of const StringVal*
Val: Move TablePatternMatcher into detail namespace
TablePatternMatcher: Use unique_ptr
IndexType: Add IsPatternIndex(), like IsSubNetIndex()
btest: Add test for pattern tables and when
Reuse CompileSet() instead of || string formatting
script optimization support for using strings to index table[pattern] values
BTests for indexing "table[pattern] of T" with strings
support for indexing "table[pattern] of T" with strings to get multi-matches
Provide a script accessible way to introspect the DFA stats that can be
leveraged to gather runtime statistics of the underlying DFA. This
re-uses the existing MatcherStats used by ``get_matcher_stats()``.
Not sure how useful this is (and the implementation isn't optimized in
any way), but seems reasonable for consistency.
Vern suggested that set[pattern] can already be achieved via
set_to_regex(), so left out any set[pattern] variants.
Seems we can just open code the CompileSet() usage in the TablePatternMatcher
helper without indirecting through another class. Further, add the collection
of indices into MatchAll() rather than duplicating its code in
MatchDisjunction(). Doesn't seem like MatchAll() is used widely.
