versions.bro uses the changing version string, which leads to changing
lines in the output of the hooks plugin, which is difficult to filter.
Hence, let's just @unload it, before it is being used.
* Clean it up, make it more consistent, and add references to similar events.
* Commented out the smb2_set_info_request event, which wasn't being generated.
* Documented the SMB2 record types in init-bare
One more name change: version_num -> version_number
BIT-1707 #merged
* origin/topic/johanna/version:
Slight naming changes for Bro version information.
Add convenient way to access version information to Bro.
Because plugins register their script directories with the BROPATH,
Broxygen stripped them out from plugin script paths it was indexing.
That then led to multiple plugins ending up with the same script
paths, triggering warnings about duplicates.
I fixed this by checking if a script comes out of a plugin. If so, it
gets an artifcial index prefix "<plugin-name>:", followed by the
script's relative path inside the plugin's top-level directory. For
example, "/opt/bro/lib/bro/plugins/Bro_Netmap/scripts/init.bro" now
turns into "Bro::Netmap:scripts/init.bro" for Broxygen purposes
(whereas it used to be just "init.bro").
Addresses BIT-1663.
(Can't think of a good way to add a test for this unfortunately.)
With the introduction of the package manager, it will get more common
that applications are able to get information about the currently
running version of Bro. With this commit, scripts can easily compare
which version of Bro they are running.
Commonly, this probably will either look like this (both lines check if
the current Bro version is greater or equal to 2.5)
@if ( Version::num >= 20500 )
or
@if ( Version::greater_equal("2.5") )
Version::info contains detailed information about the running version of
Bro, including beta flags, etc.
Looks like the right fix. Two tiny tweaks:
- changed the order of arguments for DeleteVals() for consistency
with the corresponding Manager function.
- turned the InternalWarning into a Warning: if I understand
correctly, this can happen when scripts on nodes diverge; which
is a user-side problem, not an internal Bro logic issue.
BIT-1683 #merged
* origin/topic/johanna/bit-1683:
Actually check if the number of fields in a write are equal to the number of fields required.
number of fields required.
Addresses BIT-1683
I do not think this quite fixes the underlying issue of BIT-1683 - it
should not be possible to get to this state in normal operations.
Also fixes a small memory leak for disabled writers.
(Note this a "manual" merge: I've copied just the two relevant *pac
files over, as there were a bunch of independent commits in the branch
history that I didn't want to pull in.)
BIT-1681 #merged
On OS X, Bro was failing to startup without first using the "ulimit -n"
command to increase the allowed number of open files (OS X has a much
lower default limit than Linux or FreeBSD).
The "file_extraction_limit" event was passing a Files::AnalyzerArgs
record as an "any" type. This is not right at the least and may
have been causing a crash for a user at worst.
I wasn't accounting for analyzers being disabled and not actually
instantiating when requested. This includes a test which
verifies there is no crash or problem when a user disables DCE_RPC.
