[Bro-Dev] CBAN naming

[Robin Sommer]

On Sat, Jun 04, 2016 at 20:40 +0200, Jan wrote:

> But to me a bundle/package is something different: It's a deployment
> unit, acting as some sort of container (usually enriched by metadata).
> A plugin/script itself could be used with Bro but wrapping it into the
> container allows to manage it (e.g. in terms of version, dependencies,
> etc.).

That's the way I see it, too.

I'm coming to realize something: maybe the whole confusion comes from
us reusing the plugins' internal structure: we said to reuse the same
directory layout for CBAN (for lack of of a better name ;-) because
conveniently we already have a container format that supports both
binary plugins as well as set of standalone scripts. Unfortunately,
that however now leads to conflating terminology, because suddenly
plugins already *are* that container. And that I argue is wrong,
because people writing scripts aren't writing plugins assuming any
common interpretation of that term.

So what if we stepped back and ignored how we will represent/structure
these things internally and just conceptually adapt the model Jan is
describing: we're creating *new* containers that support both scripts
and plugins, and CBAN manages these containers.  And then it becomes
an implementation detail how this will exactly look like. If we still
want to reuse the plugin structure, fine. But it would also be ok to
do something different internally if that helps avoid confusion.
Whatever it is, it would only need to make sure that after "install",
everything is layed out correctly for Bro to load it (which for binary
plugins means following their structure at the install location).

(As a side node, bringing "bro -N" into the picture makes things even
more confusing because that's *really* targeting the binary extension
stuff. For example, "-NN" wouldn't show the script code being added).

On Sat, Jun 04, 2016 at 21:23 +0000, Adam wrote:

> To me, the important part of a the definition of a plugin for most
> software is that it is an externally contributed, self/contained
> add-on which extends functionality.

Agree in principle, but "extending functionality" with a plugin is
different that just writing a new Bro script. A "plugin" typically
plugs into a set of hooks that a software provides to extend things it
doesn't provide out of the box; once loaded, that new functionality
then becomes a core feature just as if it had been built in in the
first place. I don't see, e.g., writing a script-level detector for
new vulnerability XYZ like that. If a wrote new Python module
implementing, say, BASE65 encoding, I wouldn't be adding a "plugin" to
Python either.

On Sun, Jun 05, 2016 at 15:09 +0000, Jon wrote:

> My argument is that it is true/factual/objective that scripts may used as a form of plugin.

Yes, but per above that's only because we decided to reuse the
internal structure. To me, that's arguing from an implementation-level
artefact, which isn't good starting point for defining terminology.

> And that task isn’t even difficult.  It takes a single sentence
> description: “Bro Plugins can be either compiled code, Bro scripts or
> a combination of both”.

Sure, but it's still confusing to tell people you need to write a
plugin to add your new vulnerability detector; whereas so far they
simply wrote a script. Look at the mailing list for how people have
used the term "plugin" so far: I'm pretty sure it's been only about
binary plugins. Nobody writing just a script has said "I have a
question about my plugin".

Robin


-- 
Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin