[Bro-Dev] CBrAN Bro Control Plugin
Siwek, Jonathan Luke
jsiwek at illinois.edu
Mon Oct 14 15:20:30 PDT 2013
On Oct 14, 2013, at 11:43 AM, anthony kasza <anthony.kasza at gmail.com>
> My initial thought was for the Bro project to maintain and distribute a SQLite database of rebros (git repos of Bro scripts).
A terminology nitpick: a "rebro" (according to the proposal doc) isn't a git repo, but a git repo may contain rebros (directories containing a __load__.bro script).
I'm only pointing it out to suggest the first step is that we come to a consensus on what terms to use to describe things else later discussion might get confusing.
Here's things I think need naming:
1) A git repository that may contain bro scripts.
I actually don't think these need a special name, just call it a "repo" or "repository" as usual since there's not really any unique requirements.
2) A directory containing __load__.bro.
These just let Bro "@load <dir>". "rebro" is confusing for this, since it's not a git repo itself. I've always called this a "package" for lack of anything better.
Don't think this was actually decided? Works for me, except the case switch in the middle is a bother.
> As Python2.5+ has native support for SQLite this would not require users to install additional Python modules. A community developer would be able to register his/her rebro for inclusion in the SQLite file distributed with broctl. The SQLite file would represent the universe referred to on the project page.
If the registration process were to be something simple like a person doing a pull request on GitHub where they've added their repo to the "universe" database, a flat file rather than SQLite might be better for that database file since it should be easier to change and audit (by just looking at the git commit) ?
Though if BroControl parses that file and generates some internal representation that may use SQLite, that might be one way to do it. Were you mostly thinking of storing metadata/dependency stuff there?
More information about the bro-dev