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 * [email protected] * www.icir.org/robin _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
