Re: [Bro-Dev] CBAN design proposal
> On May 23, 2016, at 5:40 PM, Robin Sommer wrote: > >> >> When a contributor submits a new script, there would be some mandatory >> checks that would need to pass for the script to be included: > > The "mandatory" is where I disagree. I believe there's just to much > involved with any initial vetting, even if conceptually simply, that > it will create a bottleneck. I guess there is a balance here. If we do no mandatory checks and you could submit something that isn’t even a Bro plugin, the repository could become cluttered with junk. Do we really want things that don’t even “compile”? I guess we can wait and see for some of these decisions, meaning start with optional and decide to make them mandatory if it becomes a problem. However, where we can’t do that is with the metadata we collect. If we don’t require what we think is important metadata in the beginning, then we will have a gap if we decide it was important all along. So there I would err towards overcorrecting in the beginning, and make things optional in the future if it turns out not to be important. ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] CBAN design proposal
On Mon, May 23, 2016 at 11:22 -0500, you wrote: > When a contributor submits a new script, there would be some mandatory > checks that would need to pass for the script to be included: The "mandatory" is where I disagree. I believe there's just to much involved with any initial vetting, even if conceptually simply, that it will create a bottleneck. Take your first question as an example: "Is the plugin structure valid?" We wouldn't get very far with a simple yes/no answer. We'd have to explain what exactly is not valid, with some of that being just convention, or maybe something that matters in general for plugins but for some reason not the particular one. Or what if the plugin works with some version of Bro, but not another. Are we going say it needs to work with the current release? What if a new release comes out and breaks all existing plugins? What if then an update for a plugin comes in that doesn't move to the new version yet? > At this point, though, I think we could run some "quality tests" and > give the plugin a quality score. This might be things like: Yep, I'm fully on board with this part, that's good information we can provide to users about the state of something. And that state could be "totally broken". :-) Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] CBAN design proposal
On Mon, May 23, 2016 at 17:26 +, you wrote: > To clarify, is the concern w/ the amount of non-automatable tasks or > with the model of requiring authors to “ping” some middle-man in order > for updates to their plugin to become visible to all CBAN users? Both actually. Putting us into the path introduces delay and requires somebody making time available. This is already not working well for the current plugin repository, where things stall because we would like to provide feedback and help guide the author along, but then don't have the cycles for actually doing that. The delay/effort will be shorter/less the more tasks can be automated, but at the beginning we won't have much automation in place I imagine and even long-term certain stuff could never be automated. So I'm wondering if we really need to be in the path at all, seems that can only cause friction that would be better to avoid in particular as we kick things off. > Because most what I had outlined could be automated Yep, understood, my mail was not directly targetting your proposal; that just triggered me thinking about this again. My comments were meant more broadly, we've been discussing different notions of vetting over time with various subsets of people. > That would make life easier for authors, and that’s maybe even a > higher priority than maximizing the quality/consistency of user > experience because, without authors, there won’t be much for users to > experience in the first place. Yeah, that's exactly what I'm advocating: making it easy should really be priority number one, with everything else coming second. If you see ways to adapt the design to target that specifically, I'm all for it. Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] Option -z
Does anybody remember what Bro's option -z is for? -z|--analyze | run the specified policy file analysis Turns out the only supported "analysis" is "notice": # bro -r x.pcap -z notice Found NOTICE: PacketFilter::Dropped_Packets Found NOTICE: PacketFilter::Install_Failure Found NOTICE: Signatures::Signature_Summary Found NOTICE: PacketFilter::Compile_Failure Found NOTICE: Signatures::Multiple_Sig_Responders Found NOTICE: Signatures::Sensitive_Signature Found NOTICE: Signatures::Count_Signature Found NOTICE: PacketFilter::Too_Long_To_Compile_Filter Found NOTICE: Signatures::Multiple_Signatures This looks very specific for hard-coded event-engine functionality. I propose to remove unless somebody still sees a use for this? Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] CBAN design proposal
> On May 21, 2016, at 5:44 PM, Robin Sommer wrote: > > I'm getting concerned that we're creating an unncessary bottleneck by > imposing the Bro Team into the critical path for submissions and > updates. Why not let people control their stuff themselves? They'd > register things with CBAN to make it available to everybody, but we'd > stay out of the loop for anything further. To clarify, is the concern w/ the amount of non-automatable tasks or with the model of requiring authors to “ping” some middle-man in order for updates to their plugin to become visible to all CBAN users? Because most what I had outlined could be automated (apart from the suggestion that initial submissions have someone from the Bro Team quickly review whether it looks legit). Though I am on board for trying to draw up a contrasting design where the focus is on directly connecting users w/ plugin authors without any blocking processes or bureaucracy in the middle-man. That would make life easier for authors, and that’s maybe even a higher priority than maximizing the quality/consistency of user experience because, without authors, there won’t be much for users to experience in the first place. - Jon ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] Coverity update
I went through the pending Converity alerts, fixed a few with my commits this morning, and marked the others as minor. I didn't see anything severe in there, most were expected. Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] CBAN design proposal
I think we're generally on the same page, but I wanted to elaborate a bit on what I envisioned with the plugin submission process. When a contributor submits a new script, there would be some mandatory checks that would need to pass for the script to be included: * Is the plugin structure valid? * Is there a valid metadata file? This file could list things like dependencies, what version of Bro the plugin works on, etc. I think the bare minimum of what needs to be in the plugin is: 1) version number and 2) license information. It's possible that we wouldn't even need the license if the submission process puts a default license on any plugin that doesn't specify otherwise. * If there are dependencies, are those already in the CBAN repository? * Is Bro able to load this plugin with --parse-only, or does it generate a parse error? * Is there already a plugin with that name and version number? If so, the author would need to increment the version. I think this is a nice balance between some bare minimum checks designed to ensure that the plugin is actually installable and not putting too much of a burden on contributors. Once a plugin has been submitted, if it passes those checks, I think it should be automatically pulled into a repo. I don't think that we need manual intervention for this. At this point, though, I think we could run some "quality tests" and give the plugin a quality score. This might be things like: * Is there documentation? (Both a README and checking to see if, for example, external redef-able consts are documented). * Are there btests? * Do the tests pass? * Does the plugin load in bare mode? These quality scores would be strictly informative, and wouldn't prevent or modify the acceptance of the plugin. What I'm imagining is something like this: https://forge.puppet.com/vshn/gitlab/scores#module-release-info --Vlad On Mon, May 23, 2016 at 10:16 AM, Robin Sommer wrote: > > > On Sat, May 21, 2016 at 23:16 +, you wrote: > > > I think there is a broad spectrum from no interaction to vetting and > > pulling into the main repository. It is about finding the right > > balance. > > Yep, and I'm arguing for going very far towards the "no interaction" > side, with just some automatic checks for the most crucial things. > Maybe the initial pull request for integration could be merged > manually to avoid any spamming, but any updates for example should not > require any interaction from us. > > > I do think there is another level of non blocking checks and quality > > control we can provide. > > Yes, indeed, I like this. With things already merged in, we can in > parallel, in the background, build up a toolbox of things to check for > and mark a module accordingly. > > Robin > > -- > Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin > ___ > bro-dev mailing list > bro-dev@bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Broker status update
On Sat, May 21, 2016 at 09:01 -0700, you wrote: > peer(x, y); // Create a peering between the two endpoints. > peer(y, x); // Idempotent. Peerings are symmetric. > x.peer(y); // Create a peering between the two endpoints. > y.peer(x); // Idempotent. Peerings are symmetric. I would prefer the 2nd way for consistenct, as all the other operations use the method-based scheme. The idempotency seems secondary to that I would say. Related question: what exactly are the semantics if only one side of the peering is set up? > - Bindings: For Python, I'm considering switching to pybind11 [1], > which provides a much more convenient API than SWIG and supports > modern C++11. Hmm ... I see the appeal but it would introduce a new dependency and its Python-specific (I assume), whereas with SWIG it's easier to add more languages later. Is that worth the benefit of switching? Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] CBAN design proposal
On Sat, May 21, 2016 at 23:16 +, you wrote: > I think there is a broad spectrum from no interaction to vetting and > pulling into the main repository. It is about finding the right > balance. Yep, and I'm arguing for going very far towards the "no interaction" side, with just some automatic checks for the most crucial things. Maybe the initial pull request for integration could be merged manually to avoid any spamming, but any updates for example should not require any interaction from us. > I do think there is another level of non blocking checks and quality > control we can provide. Yes, indeed, I like this. With things already merged in, we can in parallel, in the background, build up a toolbox of things to check for and mark a module accordingly. Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
