This field isn't publicly available via the OpenSSL 1.1 API, not used
in the base scripts, and has no example in the test suit, so removing
it is simpler than trying to support manually parsing it out of the
raw data.
The following tests currently fail due to what seems like different
behavior in OpenSSL 1.1 vs 1.0:
scripts/base/protocols/rdp/rdp-x509.bro
bifs/x509_verify.bro
* origin/topic/dnthayer/ticket1947:
Fix some typos and formatting in NEWS
Add pattern operators to the documentation of operators
Fix minor typos in broker reference documentation
Fix a broken link and some typos in broker documentation
Fix reST formatting in documentation of "count" type
Add documentation for some new Bro features
In the following example, the republication of "arg" would result in
literally sending it as a Broker::Data record instead of the broker data
that it was already wrapping.
Sender:
Broker::publish("topic", my_event, "hello")
Receiver:
event my_event(arg: any)
{
Broker::publish("topic", my_event, arg)
}
* origin/topic/vern/pattern-ops:
Update submodules to correct checkouts.
test suite updates for &/| pattern operators
documentation for &/| for patterns
side-porting changes for supporting &/| pattern ops
basic code implemented, but there's a memory problem somehwere :-(
This patch fixes a *19 year old* reference-counting bug (which could
lead to a use-after-free, not merely a leak) in the regular expression
code.
Patch by Vern Paxson.
* 'topic/vern/bit-ops' of https://github.com/bro/bro:
documentation clarification for "p1 | p2"
documentation for bitwise operators
document the '|' operator for patterns
test suite for bitwise operators brief NEWS blurb allow for "counter" operands (does anyone still use these?) for one (but not both) of the bitwise operands
bitwise operations for "count" types implemented
Starting branch for supporting bit operations on count's.
The former replaces the pcap vs. live versions of the same tuning
option. If a user does not change these, Bro makes some internal
decisions that may help avoid performance problems on systems with high
core counts: the number of CAF threads is capped at 8 and the maximum
sleep duration for under-utilized threads is increased to 64ms (CAF's
default is 10ms).
These may be used to change the number of scheduler threads that the
underlying CAF library creates. In pcap mode, it's currently hardcoded
to the minimal 4 threads due to potentially significant overhead in CAF.
