#340: Cleanup: unify where global consts are defined (access from policy layer
and event engine)
-----------------------------+--------------------
Reporter: gregor | Owner:
Type: Feature Request | Status: new
Priority: Low | Milestone: Bro1.6
Component: Bro | Version:
Keywords: |
-----------------------------+--------------------
{{{
#!rst
Global ``const``'s that are accessible from the policy layer and event
engine (e.g., to configure features) are currently defined in different
ways:
1. in ``bro.init`` and ``NetVar.{cc|h}``
2. in a specific .bro policy script and ``NetVar.{cc|h}``
3. in ``const.bif``
According to our discussion on bro-dev, we should change it to only use
``const.bif``.
For case 2. we should add a ``redef`` in the .bro policy scripts, so that
users looking at the script see that the const exists (TODO: how to best
auto-doucment these).
Setting milestone to 1.6 as it seems this can be done together with the
general policy script overhaul, but can also be pushed backed.
}}}
--
Ticket URL: <http://tracker.icir.org/bro/ticket/340>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker
#357: Only log missing support for libgeoip a single time.
---------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: Normal | Milestone: Bro1.6
Component: Bro | Version: git/master
Keywords: sprint |
---------------------+------------------------
I've seen too many people with logs that are full of messages indicating
no support for libgeoip.
--
Ticket URL: <http://tracker.icir.org/bro/ticket/357>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker
#370: Plugin interface for BroControl
-----------------------------+--------------------
Reporter: seth | Owner: robin
Type: Feature Request | Status: new
Priority: Normal | Milestone: Bro1.6
Component: BroControl | Version:
Keywords: |
-----------------------------+--------------------
Features that a first version of the plugin interface should have...
* Hooks to execute external scripts before and after start, stop, and
install.
* Mechanism for plugin scripts to provide feedback to BroControl. Maybe
just succeed or fail+message would be enough?
* Setting options for plugins in broctl.cfg. Maybe set ENV vars when
running scripts?
Currently, I'm thinking that using a naming convention for files in
<prefix>/share/broctl/plugins would work for installing plugins. Names
like this: post-install-plugin1 or pre-start-plugin2. That would provide
BroControl enough information to know which configuration options to set
in the environment when executing those scripts and when they are supposed
to be executed.
--
Ticket URL: <http://tracker.icir.org/bro/ticket/370>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker
#361: Copy Bro binary only when in NFS mode
------------------------+------------------------
Reporter: robin | Owner: robin
Type: Task | Status: new
Priority: Normal | Milestone: Bro1.6
Component: BroControl | Version: git/master
------------------------+------------------------
Currently, BroControl copies the bro binary to all clients' spool
directory, and then runs it from there. While that avoids problems
when the Bro installation is on NFS, it can cause trouble in other
contexts (like capabilities set for the binary to be lost; and I
think we had more in the past I don't recall right now).
So, the solution seems to be to avoid the copy unless in NFS mode.
We could also revisit whether we want to keep supporting runnign
from NFS at all, but generall I'd like to do so.
--
Ticket URL: <http://tracker.icir.org/bro/ticket/361>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker
#337: BroCtl's top has trouble with large values
------------------------+------------------------
Reporter: robin | Owner: robin
Type: Problem | Status: new
Priority: Normal | Milestone: Bro1.6
Component: BroControl | Version: git/master
------------------------+------------------------
From Craig:
File "/home/users/bro/bro-151/lib/broctl/BroControl/control.py", line
588, in getTopOutput
d["vsize"] = int(p[1])
ValueError: invalid literal for int(): 2.17684e+09
Here's a possible fix for this:
d["vsize"] = int(float(p[1]))
Craig
fun 2 % !!
ipython
Python 2.6.6 (r266:84292, Sep 29 2010, 08:18:31)
Type "copyright", "credits" or "license" for more information.
IPython 0.10.1 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
In [1]: p = [ 'foo', '2.17684e+09' ]
In [2]: print type(p[1])
<type 'str'>
In [3]: print p[1]
2.17684e+09
In [4]: d = {}
In [5]: d["vsize"] = int(float(p[1]))
In [6]: print d["vsize"]
2176840000
In [7]: print type(d["vsize"])
<type 'int'>
--
Ticket URL: <http://tracker.icir.org/bro/ticket/337>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker
#326: HTTP Analyzer overflow on content-lengths > 2GB
----------------------+------------------------
Reporter: gregor | Owner:
Type: Patch | Status: new
Priority: Normal | Milestone: Bro1.6
Component: Bro | Version: git/master
Keywords: inttypes |
----------------------+------------------------
{{{
#!rst
The HTTP analyzer uses 32 bit signed ints to parse the content-length
header, track body length etc. This causes overflow and for content
lengths > 2GB. This effects the reported body length as well as parsing of
pipelined or persistent connection.
The overflow might also cause crashes.
Changes in this patch:
* Change the affected integers in to 64 bit wide
* Overload min/max inline functions in util.h to work with different
widths and signedness.
* Explicitly cast parameters to min/max where in cases were the
compiler complained.
}}}
--
Ticket URL: <http://tracker.icir.org/bro/ticket/326>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker
#375: Extending record type fields
-----------------------------+--------------------
Reporter: seth | Owner:
Type: Feature Request | Status: new
Priority: Normal | Milestone: Bro1.6
Component: Bro | Version:
Keywords: logging |
-----------------------------+--------------------
One proposal for giving users the ability to add their own fields to the
record type used for logging to a particular stream in the new logging
framework involves redef-ing the record type to add new fields. Example
syntax:
{{{
module SSH;
type Log = record {
client: string;
server: string;
}
redef type SSH::Log += {
id: conn_id &optional;
};
}}}
I'm even thinking that fields added in redefs could even be mandatory or
implicitly &optional to avoid causing errors with shipped scripts.
--
Ticket URL: <http://tracker.icir.org/bro/ticket/375>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker
#374: Add type testing operator
-----------------------------+--------------------
Reporter: seth | Owner:
Type: Feature Request | Status: new
Priority: Normal | Milestone: Bro1.6
Component: Bro | Version:
Keywords: |
-----------------------------+--------------------
This is needed for generic filtering of log records in the logging
framework. Initial discussions have used a syntax like this:
{{{
function generic_outbound(rec: any)
{
rec$?<conn_id>cid
...
}}}
That syntax would check that the record type instance 'rec' has a field
named 'cid' with the type 'conn_id'.
--
Ticket URL: <http://tracker.icir.org/bro/ticket/374>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker
#325: Remove ACTIVE_MAPPING code
------------------------+---------------------
Reporter: robin | Type: Problem
Status: new | Priority: Normal
Milestone: Bro1.6 | Component: Bro
Version: git/master |
------------------------+---------------------
The configure option is already gone, let's not forget to remove the
code as well.
--
Ticket URL: <http://tracker.icir.org/bro/ticket/325>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker