- Move all of the time handling code out of PktSrc into RunState
- Call packet_mgr->ProcessPacket() from various places to setup layer 2 data in packets
* origin/topic/jsiwek/zeek-script-args:
Improve zeek_script_args test case and documentation
Apply suggestions from code review
Add a test for script args.
Fixed an option processing bug
Make it possible to pass command line options through to scripts.
- Minor adjustments to whitespace/formatting
* origin/topic/seth/pcap_findalldevs:
Finishing changes from code review.
Update src/iosource/pcap/pcap.bif
Update src/iosource/pcap/pcap.bif
Update scripts/base/init-bare.zeek
Update src/iosource/pcap/pcap.bif
I accidentally missed a paren
New bif to wrap pcap_findalldevs
generate_all_events causes all events to be raised internally; this
makes it possible for dump_events to really capture all events (and not
just those that were handled).
Addresses GH-169
It accepts "originator" or "responder" states as a way to enforce that
the signature only matches packets in the associated direction.
The "established" state is rejected as an error since it doesn't
have a useful meaning like it does for the "tcp-state" condition.
Clang supports `#pragma GCC diagnostic` for "compatibility", but not
`-Wmaybe-uninitialized`, so was emitting `warning: unknown warning group
'-Wmaybe-uninitialized'`
(Adding a NEWS entry.)
* origin/topic/christian/364-logfilter-hooks:
Update testing/btest/scripts/base/frameworks/logging/hooks.zeek
Btests for log filter policy hooks
Btest baseline updates to reflect new logging policy hooks
Migrate existing use of filter predicates to policy hooks
Support for log filter policy hooks
- Removed a now-unused-local-variable
- Added std::move() in AssignExpr::SetOp2()
* origin/topic/robin/gh-425-record-perf:
Avoid unnecessary temporary value when coercing a record that's already the right type.
Optimize record constructor expression.
Unify type comparisions for records.
- Improved documentation/comment for the new option
* 'logging-ascii-enable-shadow-logs' of https://github.com/awelzel/zeek:
logging/ascii: Support leftover log rotation in non-supervisor setups
We remove the inheritance from UnaryExpression because we know the
type of the operand precisely and can skip a temporary when evaluating
the expression.
#425
For records, same_type(r1, r2) would not check if the fields'
attributes match as well. That seems like an oversight, and some
callers of same_type() did indeed add that check on their end. This
commit moves the check into same_type() itself. That generally doesn't
seem make any differences except for a couple of places validating
code, which we update a bit. That in turn leans to slightly different
(better?) error messages for a couple of test cases.
We have a use case to rotate leftover log files in a non-supervisor
setup. There doesn't seem to be a strict requirement on supervisor
functionality. Allow enabling leftover log rotation through
LogAscii::enable_leftover_log_rotation and redef this for the
logger node in a supervisor setup individually.
This adds a "policy" hook into the logging framework's streams and
filters to replace the existing log filter predicates. The hook
signature is as follows:
hook(rec: any, id: Log::ID, filter: Log::Filter);
The logging manager invokes hooks on each log record. Hooks can veto
log records via a break, and modify them if necessary. Log filters
inherit the stream-level hook, but can override or remove the hook as
needed.
The distribution's existing log streams now come with pre-defined
hooks that users can add handlers to. Their name is standardized as
"log_policy" by convention, with additional suffixes when a module
provides multiple streams. The following adds a handler to the Conn
module's default log policy hook:
hook Conn::log_policy(rec: Conn::Info, id: Log::ID, filter: Log::Filter)
{
if ( some_veto_reason(rec) )
break;
}
By default, this handler will get invoked for any log filter
associated with the Conn::LOG stream.
The existing predicates are deprecated for removal in 4.1 but continue
to work.
After detecting a closing-boundary for a given multipart MIME entity, it
enters into an "end of data" state, however any subsequent boundary
delimiter could still cause the allocation of a sub-entity object that
is never released due to cleanup logic being bypassed upon finding the
"end of data" state already reached.
This change prevents allocation/processing of sub-entities after the
"end of data" state is reached (e.g. from detecting a multipart
closing-boundary). This new behavior still aligns with RFC 2046
expectations:
"There appears to be room for additional information prior to the first
boundary delimiter line and following the final boundary delimiter line.
These areas should generally be left blank, and implementations must
ignore anything that appears before the first boundary delimiter line or
after the last one."
Credit to OSS-Fuzz for discovery
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26027
(Link to details becomes public 30 days after patch release)
- Changed the new stub events to correctly check for existence of
their associated handler before generating an event
- Added a test case for the new stub event
* 'add-dce-rpc-payloads' of https://github.com/ynadji/zeek:
Add stub payload to dce_rpc_request and dce_rpc_response
