[Bro-Dev] CBrAN Bro Control Plugin
robin at icir.org
Mon Oct 14 20:11:53 PDT 2013
Great to see you're up for tackling this, it's one of the major
missing pieces in the Bro world (universe? :).
I like Jon's terminology, and I agree that a flat file will probably
work better than an SQL lite database for storing that meta
information. I don't think the input framework needs to parse it, I
picture all of this being handled outside of Bro itself (i.e., by
I actually need to go back to the project page to remind myself of the
specifics there; it's been a while since that went up and we might
want to update a few things. I'd be happy to chat sometime to flesh
this out further.
On Mon, Oct 14, 2013 at 17:24 -0700, you wrote:
> Having a name for a directory resembling "repo" when the directory is
> not a repository is confusing, I agree. I'll refer to it as a package
> moving forward.
> The project page refers to the package manager as CBAN, let's go with that.
> Having a flat file representation of the universe would make managing
> the universe through GitHub much simpler. It would also save people
> from having to write a bunch of SQL code.
> My thought was for the universe database to contain the following
> pieces of information (taken from the project page): name, URL,
> author, tags, package version, Bro version, dependencies, license,
> description. If a plain text flat file is used would would it be
> useful for the file to be readable by the input framework?
> On Mon, Oct 14, 2013 at 3:20 PM, Siwek, Jonathan Luke
> <jsiwek at illinois.edu> wrote:
> > On Oct 14, 2013, at 11:43 AM, anthony kasza <anthony.kasza at gmail.com>
> > wrote:
> >> 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.
> > 3) CBrAN
> > 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?
> > - Jon
> bro-dev mailing list
> bro-dev at bro.org
Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org
ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin
More information about the bro-dev