[Bro-Dev] CBAN naming

Siwek, Jon jsiwek at illinois.edu
Sun Jun 5 13:31:34 PDT 2016

> On Jun 5, 2016, at 10:55 AM, Robin Sommer <robin at icir.org> wrote:
> So what if we stepped back

Yes, generally we may need to step back.  I think this thread started based on the idea that the names of things are entirely subjective and separate from the technical design.  But that’s not true — I need to be able to write unambiguous documentation and the choice of using plugins as the top-level container type means that introducing any other name for that container is creating an ambiguity.  So yes, we can revisit the choice to use plugins as the top-level container.

> 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

Yes, that could be a way to do things if I understand it right as:

- New Container
	- Script Container (e.g. what is currently called “script package”)
	- Compiled Code Container (e.g. what is currently called “plugin”)

Another idea is to not have any new container and allow the Script Container and Compiled Code Container to live at the top of the hierarchy as siblings.  I think they could still share a common metadata format.  It would also still be possible for a person to promote their Script Container to a Compiled Code Container if they find that they need that level of functionality.

> (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).

Yeah, I see how that’s a bit messy now, but skeptical because it might not be much of a fuss to just change/improve the output of a command line argument.

> On Sat, Jun 04, 2016 at 21:23 +0000, Adam wrote:
> If a wrote new Python module
> implementing, say, BASE65 encoding, I wouldn't be adding a "plugin" to
> Python either.

Correct, you didn’t write a plugin to Python, but if you had an application called "Foo" that allows users to specify custom encoding schemes via Python scripts, then you wrote a plugin for “Foo”.

So while a Bro script isn’t a plugin for the Bro language, it is a plugin for the Bro application.

> 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.

But writing such a script does extend Bro w/ new functionality that it doesn’t provide out of the box, so it seems to fit your definition of a plugin as well.  The only difference I see is that a script is more limited in how far it can extend functionality, but that’s not a binary property you can use to easily categorize plugin vs. non-plugin.

The way I see it: one set of “plugin hooks" that the Bro application provides is the Bro scripting language itself and all the APIs/BIFs/events that are available within it.

> 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.

But I’m not just arguing based upon the way Bro’s plugins are implemented, I’m arguing about plugins in general.  There exists applications that use scripts as a form of plugin.

So I’m saying it’s actually a Good Thing that Bro plugins can be script-only or additionally use compiled code, even if it was not intentional because it fits an even wider description of the term “plugin”.

But if you still don’t like that plugins can be used for scripts-only, then we should probably revisit the design so that we aren’t using them in that way (e.g. the ideas presented near the top of this email).

>> 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;

They only need to write a plugin if they plan to distribute it so that it works w/ the new plugin manager tool.  I don’t see how that can lead to confusion, but I do see how maybe that could be more tedious than they would like :)

We can address this problem by designing the manager to seamlessly deal with both script-only containers as well as compiled-code containers like we were thinking about above.

> 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.

But that doesn’t negate the truth that plugins currently may be either script-only or binary.  And those past discussions don’t become invalidated if we move to using script-only plugins more generally.

> Nobody writing just a script has said "I have a
> question about my plugin”.

Because at the time they said that, they weren’t authoring a plugin, they were writing a script :)

People don’t currently have a reason to put their scripts inside a plugin, so that’s why no one uses that wording and goes down that path.  The incentive for them to start putting their script within a plugin would be the existence of a tool that manages plugins as a top-level container.

I think it may be worth it to do another design pass to see if can find any problems w/ either the super-container or sibling-container approach as outlined at the top.  I do like those ideas and only see improvements and no drawbacks (apart from implementation code complexity, which doesn’t count for much), so I don’t mind wrapping my head around it for a bit longer to see if it’s a better fit.  Unless I’ve convinced you that “plugin” as the top-level container is the way to go?

- Jon

More information about the bro-dev mailing list