Re: [Bro-Dev] Plugin branch status

On May 17, 2013, at 10:02 PM, Seth Hall s...@icir.org wrote: On May 17, 2013, at 9:17 PM, Robin Sommer ro...@icir.org wrote: So, my question is if I should go ahead merging this into master for 2.2. I say let's go for it in 2.1, except that your point about the documentation is worth

Re: [Bro-Dev] viability of stand-alone (not installed) Bro

I don't think that is intended behavior, but rather an unintended consequence of some of the work on the file analysis framework and shipping with our own magic DB. Perhaps Jon can elaborate more on what it would take to fix this? On Jul 29, 2013, at 10:09 PM, Vern Paxson v...@icir.org wrote:

Re: [Bro-Dev] Dot release?

I like that plan. I think there are some minor Maverick's issues too that Daniel found. So we might want to get those in there as well. On Jan 30, 2014, at 10:50 AM, Robin Sommer ro...@icir.org wrote: Folks, making a 2.2.1 release has been coming up a few times and I'm thinking we should

Re: [Bro-Dev] [JIRA] (BIT-1215) bro-cut should be rewritten in C for speed and to not depend on gawk

We are going to make it configurable and default to like a 1000KB line. Otherwise, you add a check to see if you need to reallocate memory for every line processed, which seems inefficient for edge cases. Letting the user override the default is a good compromise though. On Jul 10, 2014, at

Re: [Bro-Dev] Geo Location Plugin

I think that is reasonable for some things. On Oct 16, 2014, at 8:02 AM, Robin Sommer ro...@icir.org wrote: (unless we decide to build (some) plugins by default, which currently isn't happening). -- Adam J. Slagell Chief Information Security Officer Assistant Director, Cybersecurity

[Bro-Dev] Bro Project and the Software Freedom Conservancy

by the end of this week as I’d like to have something to announce at BroCon. Thanks, Adam Slagell -- Adam J. Slagell Chief Information Security Officer Assistant Director, Cybersecurity Directorate National Center for Supercomputing Applications University of Illinois at Urbana-Champaign

[Bro-Dev] Brokerization of iSSHD

I’m checking to see if anyone is already working on converting the ssllogmux script used by iSSHD to use Broker? I don’t think the corresponding bro scripts will need to be updated unless they are using , right? :Adam -- Adam J. Slagell Chief Information Security Officer Director,

Re: [Bro-Dev] CBAN naming

> On Jun 2, 2016, at 3:37 PM, Matthias Vallentin wrote: > >> So with that said, I propose bro-pkg, but will leave this open for >> another day if there are strong opinions. > > I like "bro-pkg," though I wonder whether it could be even shortened to > "bpkg" or "bkg." It

Re: [Bro-Dev] CBAN naming

> On Jun 2, 2016, at 10:56 AM, Siwek, Jon <jsi...@illinois.edu> wrote: > >> >> On Jun 1, 2016, at 5:30 PM, Slagell, Adam J <slag...@illinois.edu> wrote: >> >> These are variants of #1, which I now substitute with bro-pkg > > Related to “pkg” or

Re: [Bro-Dev] CBAN naming

> On Jun 4, 2016, at 1:09 PM, Robin Sommer wrote: > > The primary way we've used "plugin" so far is as a compiled, > binary extension. I'm not sure we all have or that the project has used it consistently in that way. It is new enough to Bro I'm not bothered if we shift it

Re: [Bro-Dev] CBAN naming

> On Jun 2, 2016, at 4:40 PM, Jan Grashöfer wrote: > > The point here was that bro-pkg would align to bro-cut. Although I still > like brow, I would prefer bro-pkg or bropkg to bpkg and bkg. While > b(p)kg could be anything bro-pkg is clearly bro-related. Agreed. And

Re: [Bro-Dev] CBAN naming

> On Jun 3, 2016, at 1:59 PM, Siwek, Jon <jsi...@illinois.edu> wrote: > >> >> On Jun 2, 2016, at 3:13 PM, Slagell, Adam J <slag...@illinois.edu> wrote: >> >> It looks like that term is just used here for “Script packages” and on all >> the auto

Re: [Bro-Dev] CBAN naming

> On Jun 5, 2016, at 10:55 AM, Robin Sommer 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

Re: [Bro-Dev] New proposal (Re: CBAN naming)

> On Jun 6, 2016, at 9:46 PM, Robin Sommer wrote: > >> >> That all looks consistent except part (2) ends up pointing people >> toward existing docs/examples that reference “package” but with a >> different meaning. I'd need a decision to be made about how/whether >> to change

Re: [Bro-Dev] CBAN design proposal

> On May 25, 2016, at 12:12 AM, Robin Sommer wrote: > > Overall, I agree that we can always add more restrictions later if it > turns out necessary. It's not that we'll have 1000s of Bro modules in > there within the first two weeks (as long as we prevent somebody > spamming us

Re: [Bro-Dev] CBAN design proposal

> On May 25, 2016, at 11:25 AM, Siwek, Jon <jsi...@illinois.edu> wrote: > >> >> On May 25, 2016, at 9:49 AM, Slagell, Adam J <slag...@illinois.edu> wrote: >> >> So this has become an involved thread. Do we need a call, or do you think >> you ca

Re: [Bro-Dev] CBAN naming

Think the current name is fine, but if you change it I think it helps if it relates to things people know. So names like bpkg, bro-ports, or bro-brew would give the immediate analogy through the name. > On May 27, 2016, at 12:00 PM, Matthias Vallentin wrote: > > To find

[Bro-Dev] Something to think about as we build Bro Package Manager

http://arstechnica.com/security/2016/06/college-student-schools-govs-and-mils-on-perils-of-arbitrary-code-execution/ -- Adam J. Slagell Chief Information Security Officer Director, Cybersecurity Division National Center for Supercomputing Applications University of Illinois at

Re: [Bro-Dev] CBAN naming

> On Jun 4, 2016, at 10:45 AM, Siwek, Jon wrote: > > My last understanding is that we’re starting out w/ metadata being entirely > optional and seeing how it goes. This also makes it more convenient for > people to use the tool to manage plugins they have no intention of

Re: [Bro-Dev] CBAN design proposal

> On May 26, 2016, at 10:46 AM, Robin Sommer wrote: > > - Terminology 1: agree that we should find a better name for CBAN. BroForge? > > - Terminology 2: Using "plugin" as the entity name for everything is > confusing I think, as right now I think most people understand it

Re: [Bro-Dev] CBAN naming

> On Jun 2, 2016, at 10:56 AM, Siwek, Jon wrote: > > Related to “pkg” or “package” naming: if that terminology gets used, what > would be done about the classic/existing usage of the term “package” within > Bro? > > “Package” is currently used to refer to any collection

Re: [Bro-Dev] CBAN naming

I have gone over a bunch of these threads and want to bring this back towards consensus, or at least consilience. Let’s pick from the following 5 options, and then we can decide if these are bundles, ports, packages, plugins, extensions, modules, or bags. Key criteria are clarity and

Re: [Bro-Dev] CBAN naming

> On May 31, 2016, at 12:54 PM, Matthias Vallentin wrote: > >> >> I favor “bagger” or “bagboy” along with “bags”. > > I did not get the "bagger" and "bagboy" variations until I googled it, > probably because I'm not a native speaker. However, I like the grocery > bag

Re: [Bro-Dev] Bro plugins + broctl plugins?

https://bro-tracker.atlassian.net/browse/BIT-1551 > On Jun 23, 2016, at 11:48 AM, Seth Hall wrote: > > Has any movement been made on the ability to add broctl plugins into bro > plugins? I know we talked about it a few times, and it's sort of becoming > necessary are more

Re: [Bro-Dev] [JIRA] (BIT-1571) Connection summaries w/ IPv6 have poor readabiity

Or don’t count it in the port statistics, but still count it in the protocol stats. So you would see a ton of protocol #1 But I think I like your suggestion better because it separates things like 53/tcp and 53/udp. On Apr 26, 2016, at 9:04 AM, Vlad Grigorescu

Re: [Bro-Dev] CBAN design proposal

> On May 24, 2016, at 4:46 PM, Matthias Vallentin wrote: > > If I understold it correctly, I don't think that the central CBAN > repository will accumulate clutter. The automatic checks will help > simply age out repos that do not comply with the minimal standards. It's > up

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

Re: [Bro-Dev] CBAN design proposal

> On May 24, 2016, at 11:21 AM, Siwek, Jon wrote: > > I think all those points make things easy on contributors, minimize direct > involvement of the Bro Team in sorting out problems related to particular > plugins, and provide a useful way for users to discover and

Re: [Bro-Dev] CBAN design proposal

> On May 24, 2016, at 12:07 PM, Siwek, Jon <jsi...@illinois.edu> wrote: > >> >> On May 23, 2016, at 6:30 PM, Slagell, Adam J <slag...@illinois.edu> wrote: >> >> I guess there is a balance here. If we do no mandatory checks and you could >&g

Re: [Bro-Dev] CBAN design proposal

> On May 21, 2016, at 5:44 PM, Robin Sommer wrote: > > As I read through the design doc, I started questioning our plan of > curating CBAN content. I know that's what we've been intending to do, > but is that really the best approach? I don't know of script > repositories for

[Bro-Dev] Detecting protocols without full analyzers

Some of the core developers of Bro have been having this discussion internally, and I’d like to bring it to the broader community. It has been recognized that there are a lot of protocols for which we don’t have full analyzers that some would still like to detect in our conn.logs via simple

Re: [Bro-Dev] Detecting protocols without full analyzers

> On May 9, 2016, at 11:20 AM, Robin Sommer wrote: > > Actually I would propose something else: we recently added minimal > analyzers for IMAP and XMPP that parse just the beginning of a > session---just enough to confirm the protocol and, in these cases, > also use of SSL.

Re: [Bro-Dev] package manager progress

Hhhm, is it naming conventions that people have a problem with or the implication of policing? These can be separated. I don’t see a downside to promoting conventions. It also seems that some of the reason (e.g., that we have metadata is based on an assumption that we will have good

Re: [Bro-Dev] package manager progress

> On Aug 5, 2016, at 12:52 PM, Robin Sommer wrote: > >> >> Hhhm, is it naming conventions that people have a problem with or the >> implication of policing? > > The problem is that the suggested naming convention wouldn't work: > it's not clear how somebody would name their

Re: [Bro-Dev] package manager progress

> On Aug 5, 2016, at 6:37 PM, Siwek, Jon <jsi...@illinois.edu> wrote: > > >> On Aug 5, 2016, at 1:29 PM, Slagell, Adam J <slag...@illinois.edu> wrote: >> >> If we are going to rely on metadata, which I agree can be better as you can >> tag

Re: [Bro-Dev] bro-pkg -> bropkg

Someone did come up to me and ask about that during BroCon. I am indifferent, just please let’s not open up the whole tool name naming conversation. I don’t think I can take that again. :-) > On Sep 15, 2016, at 9:27 AM, Seth Hall wrote: > > What does everyone think about

Re: [Bro-Dev] Updating NEWS for 2.5

Thanks. Let’s space out our blogs a little bit (We posted one yesterday on bro-pkg) and save this one for after the 2.5 release. > On Oct 4, 2016, at 4:09 PM, Jan Grashöfer wrote: > > Meanwhile I have added Michal's suggestions and he reviewed again: >

Re: [Bro-Dev] bro-pkg -> bropkg

Let's hold off if we might be renaming Bro On Sep 16, 2016, at 4:17 PM, Matthias Vallentin wrote: >> Bropkg is easier to type indeed. And then let's change the brocut. > > Yeah, all bro* utils should be consistent. If we change bro-pkg, then > bro-cut must undergo the same

[Bro-Dev] Blog post for bro-pkg

Jon, Would you be up for writing a blog post introducing the Bro Package Manager and showing some examples of its use? We probably also want to state that these are unvetted contributions from the community. :Adam -- Adam J. Slagell Chief Information Security Officer Director,

Re: [Bro-Dev] OpenFlow Analyzer

Have you looked at the netcontrol framework in Bro, developed by Johanna? > On Oct 17, 2016, at 2:24 PM, Hui Lin (Hugo) wrote: > > Hi > > My understanding is that Bro has some northbound API to openflow switches or > controllers. I am wondering whether any development

Re: [Bro-Dev] OpenFlow Analyzer

openflow protocol or not (some refer them > as southbound traffics). It not, I probably need to use wireshark to output > the pcap and analyze them manually. > > On Mon, Oct 17, 2016 at 2:37 PM, Slagell, Adam J <slag...@illinois.edu > <mailto:slag...@illinois.edu>> wrote:

Re: [Bro-Dev] Updating NEWS for 2.5

On Dec 1, 2016, at 4:32 AM, Jan Grashöfer wrote: >> Thanks. Let’s space out our blogs a little bit (We posted one yesterday on >> bro-pkg) and save this one for after the 2.5 release. > > As 2.5 has been released and there have already been some questions on > the

Re: [Bro-Dev] early performance comparisons of CAF-based run loop

That might be useful. I would like Robin’s thoughts, too. On Apr 12, 2017, at 9:05 PM, Siwek, Jon > wrote: In the near-term, I can make a totally separate code branch that simply replaces select() with epoll. Then, if Justin were to test it and

Re: [Bro-Dev] 2.5.1 release?

> On May 12, 2017, at 4:09 PM, Seth Hall wrote: > > I'd be fine with that. I think master is quite stable right now anyway I'm pretty sure Vlad is in agreement, but traveling today. I think Justin as well, but I should let him speak for himself.

Re: [Bro-Dev] 2.5.1 release?

On May 12, 2017, at 4:08 PM, Seth Hall > wrote: I'd be fine with that. I think master is quite stable right now anyway. Agreed. My understanding is that we still have some stochastic tests that fail for timing issues, but not if run manually on

Re: [Bro-Dev] bro-pkg dependencies ?

At list recursively finding all of those dependencies is on the roadmap. Terry has that on his queue. > On Sep 8, 2017, at 12:29 PM, Aashish Sharma wrote: > > Can we specify dependent packages in bro-pkg and would bro-pkg go and resolve > (install) those dependencies by itself

[Bro-Dev] Bro working well on Mac OS High Sierra, just a couple test failures

I had no problems after the upgrade to High Sierra on my “production” box, and I had no troubles compiling Bro 2.5.1 on my laptop. I did, however, get a two errors in the test suite. core.truncation ... failed % 'btest-diff output' failed unexpectedly (exit code 1) % cat .diag == File

Re: [Bro-Dev] Performance Enhancements

On Oct 5, 2017, at 2:45 PM, Jim Mellander > wrote: 1. Obviously, branch prediction, as mentioned above. 3% speedup for (almost) free is nothing to sneeze at. 2. Profiling bro to identify other hot spots that could benefit from optimization. 3.

Re: [Bro-Dev] Bro working well on Mac OS High Sierra, just a couple test failures

On Oct 4, 2017, at 2:14 PM, Thayer, Daniel N > wrote: The second failure looks like another race condition (try again a few times and it will likely pass). Right you are. 4th time’s a charm. :-) -- Adam J. Slagell Director,

Re: [Bro-Dev] Broker has landed in master, please test

On May 23, 2018, at 3:12 PM, Michael Dopheide > wrote: Do you want dumb programming questions asked here or on the main Bro list? While most people might not need it yet, discussion there might help get more people interested or help avoid issues with

Re: [Bro-Dev] Moving to GitHub?

On May 18, 2018, at 11:11 AM, Robin Sommer > wrote: What I was envisioning is more or less a clean slate: we'd migrate over a few tickets, but essentially we'd start with an empty list. I realize that sounds pretty harsh. However, I hardly ever see any

Re: [Bro-Dev] Moving to GitHub?

I am in favor. I would like to still maintain the the Jira and wiki for a couple months until we finish up some work. Really just the BPM tickets. > On May 15, 2018, at 7:19 PM, Robin Sommer wrote: > > This has been coming up in various contexts & subgroups of people, and > I

Re: [Bro-Dev] "bro" name is non-inclusive? (Contribution is rejected based )

The project announced that it is changing its name this fall. We are still in the process of doing this. See http://blog.bro.org/2017/10/a-new-name-for-bro-project.html There was also a note in early January noting that the project was seeking outside help from a branding firm, and so there