[Bro-Dev] Script reorg proposal

Gregor Maier gregor at icir.org
Tue Aug 2 08:46:02 PDT 2011

On 8/2/11 7:58 , Robin Sommer wrote:
>> having to go from-all-to-nothing. Then we could also just use a single
>> (base) directory for all the scripts instead of bro/base and bro/policy
>> (which kinda irks me).
> One of the main motivations for the proposed reorg is actually to
> split the two apart. Currently, they are all inside one directory
> hierarchy, but that makes it hard to get a good picture of what's
> there.

I think that needs to be solved by documentation. Have some (short) doc 
that lists everything that's @load'able and briefly describes what it 

> With a default.bro that would get even worse becauese now one
> would need to check that file to see what's already loaded.

One option would be to put everything that's @load'able into the 
default.bro file and comment everything that we don't load per default. 
We could also include the descriptions I mentioned above as comments.

> With the two dirs split, there'll probably be some top-level.bro in
> base/ pulling in all the other stuff. To remove only some parts one
> could either copy-and-edit that file, or (better where it works)
> @unload stuff. But in any case, that's something only "the experts"
> would be doing anyway.

So this top-level.bro is basically the same as my default.bro except it 
lives in base/, right? So what's the advantage? That it's easy to see 
what's loaded by default based on the directory where the script is?

If that's indeed the case and you want to do the split into two 
directories, I would still advocate to do top-level.bro the way I 
described my default.bro, i.e., but it in /site and add comments to make 
it "user serviceable" :-)

Another question would be whether one would split protocol analysis 
between base and policy? E.g., is there going to be "base/http/" and 
"policy/http" and when I load the first as package I get the basic and 
when I also load "policy/http" as package I get the heavier analysis or 
would I also cherry-pick additional features in "policy/http/*"?


(1) This list of @load'able things should be sorted thematically which 
shouldn't be so hard given that we already have the directory structure. 
We can proably also get the descriptions from the autodoc feature.

Gregor Maier
<gregor at icir.org>  <gregor at icsi.berkeley.edu>
Int. Computer Science Institute (ICSI)
1947 Center St., Ste. 600
Berkeley, CA 94704, USA

More information about the bro-dev mailing list