Re: [Bro-Dev] Documenting Weirds

On Jun 27, 2014, at 3:35 PM, Vlad Grigorescu v...@grigorescu.org wrote: Is there a mechanism in Broxygen to document weirds? If not, has anyone thought about what such a mechanism might look like? There’s not currently a mechanism. Things that Broxygen can easily aid in documenting are

Re: [Bro-Dev] Organizing plugins (Re: [JIRA] (BIT-1222) topic/robin/reader-writer-plugins)

On Aug 4, 2014, at 3:48 PM, Robin Sommer ro...@icir.org wrote: So, in short: what would you guys think about solving the problem by moving DataSeries and ElasticSearch (including their scripts and tests) out into a new bro-plugin repository, but otherwise leaving things as they are right

Re: [Bro-Dev] Organizing plugins (Re: [JIRA] (BIT-1222) topic/robin/reader-writer-plugins)

On Aug 5, 2014, at 4:41 PM, Robin Sommer ro...@icir.org wrote: On Mon, Aug 04, 2014 at 22:03 +, you wrote: Yeah, seems like a reasonable first-step. I’m wondering if it makes sense to break them up even further in to separate repos like dataseries-bro-plugin and

Re: [Bro-Dev] Organizing plugins (Re: [JIRA] (BIT-1222) topic/robin/reader-writer-plugins)

On Aug 6, 2014, at 10:00 AM, Robin Sommer ro...@icir.org wrote: So do we want to go ahead with this model? Sure. I’m thinking if a problem is found, it’s not hard to convert to one of the other models since they should share the same directory structure and only differ in which dirs are

Re: [Bro-Dev] [JIRA] (BIT-1236) topic/jsiwek/flip-on-syn-ack

On Aug 25, 2014, at 4:40 PM, Vlad Grigorescu v...@grigorescu.org wrote: Does it makes sense that following a connection teardown, if a SYN-ACK is seen, a new connection begins, instead of using the existing connection? I can probably grab a PCAP if necessary. Actually, I’m thinking it may

Re: [Bro-Dev] [JIRA] (BIT-1236) topic/jsiwek/flip-on-syn-ack

On Aug 26, 2014, at 5:02 PM, Vlad Grigorescu v...@grigorescu.org wrote: The specific issue is that the jump in seq numbers between the first and second connection cause Bro to think that a lot of traffic was simply missed. This leads to false positives with the SSH heuristic, since now

Re: [Bro-Dev] [Bro-Commits] [git/bro] topic/jsiwek/improve_comm_loop: Remove timeouts from remote communication loop. (675fba3)

Feedback and/or help testing is welcome. - Jon On Aug 28, 2014, at 1:36 PM, Jonathan Siwek jsi...@ncsa.illinois.edu wrote: Repository : ssh://g...@bro-ids.icir.org/bro On branch : topic/jsiwek/improve_comm_loop Link :

Re: [Bro-Dev] [Bro-Commits] [git/bro] topic/jsiwek/pktsrc-idle: Fix packet sources being treated as idle when a packet is available. (31b7e98)

Yeah, if it reports itself as idle while a packet was just retrieved, then whether or not it’s actually a candidate to be Process()’d can depend on the result of a subsequent select() — seems problematic :) - Jon On Oct 2, 2014, at 2:34 PM, Robin Sommer ro...@icir.org wrote: Never mind, I

Re: [Bro-Dev] Plugins providing threads?

On Oct 8, 2014, at 12:47 PM, Clark, Gilbert gc355...@ohio.edu wrote: Would it make sense to replace the existing inter-thread communication code with the broker / porting the existing writers and readers to use the actor framework? This way, there would only be a single, shared

Re: [Bro-Dev] Geo Location Plugin

On Oct 14, 2014, at 7:48 PM, anthony kasza anthony.ka...@gmail.com wrote: From what I can tell, I don't have geo_location = internal_type(geo_location)-AsRecordType(); in the right location. This line is from the init_net_var() function from NetVar.cc, which gets called by main.cc.

Re: [Bro-Dev] Geo Location Plugin

On Oct 17, 2014, at 8:16 AM, Robin Sommer ro...@icir.org wrote: (2) Select some plugins in bro-plugins that build automatically with Bro. (3) Split bro-plugins into two repositories. One set would build with Bro, the other not. We'd need to decide if both would be

Re: [Bro-Dev] [JIRA] (BIT-1270) topic/gilbert/plugin-api-tweak

On Oct 17, 2014, at 1:34 PM, Gilbert Clark gc355...@ohio.edu wrote: To be honest, I'm not sure if expecting a user to return a std::pairbool, Val* from a plugin function hook is more or less obvious than an explicit wrapper. One thing that makes this a little less obvious to me is that

Re: [Bro-Dev] [JIRA] (BIT-1270) topic/gilbert/plugin-api-tweak

On Oct 20, 2014, at 10:05 AM, Robin Sommer ro...@icir.org wrote: So one thing to keep in mind is that not many people will ever write code using this; it's just for function hooks, and I imagine their use will be limited. I'm personaly still leaning towards the pair, but it's not a big

Re: [Bro-Dev] libbroker status/plans

On Oct 22, 2014, at 3:45 PM, Thayer, Daniel N dntha...@illinois.edu wrote: Why does it need version 2.8.12 of cmake? 2.8.8+ for object library targets and 2.8.12+ for MACOSX_RPATH (http://www.kitware.com/blog/home/post/510). Don’t see these as strict requirements, but simplifies some

Re: [Bro-Dev] libbroker status/plans

On Oct 23, 2014, at 11:04 AM, Seth Hall s...@icir.org wrote: On Oct 23, 2014, at 11:41 AM, Siwek, Jon jsi...@illinois.edu wrote: it may just push the overload problem to the sender(s) and begs the question of what they do if they can’t artificially slow down? With regards to logging

Re: [Bro-Dev] libbroker status/plans

On Oct 23, 2014, at 2:47 PM, Robin Sommer ro...@icir.org wrote: - C API Yeah, I would like to have this early on. In principle, we could postpone to later, but it looks like one of these things that if we don't get it into place right away, it will be even harder to do later. Maybe

Re: [Bro-Dev] libbroker status/plans

On Oct 23, 2014, at 5:20 PM, Robin Sommer ro...@icir.org wrote: What I meant was ensuring the two stay in sync. Say if we added a new capability to C++, can we trigger somehow a test failure if we forget to add it to C? Don’t have any ideas for how to do that at the moment, but, yes, it

Re: [Bro-Dev] Help Troubleshooting a Perftools Memleak

On Oct 29, 2014, at 10:35 PM, Robin Sommer ro...@icir.org wrote: Unfortunately the obvious fix doesn't work. I'm pasting it in below, but that change lets Bro crash because it now depends on the order in which global constructors run. If anybody has a better idea, let me know. Extending

Re: [Bro-Dev] libbroker status/plans

On Nov 3, 2014, at 3:48 PM, Robin Sommer ro...@icir.org wrote: On Thu, Oct 23, 2014 at 21:59 +, you wrote: I started looking in to this a little and I’m thinking either LevelDB or RocksDB may be good default choices to use here. I looked over them a bit, and RocksDB looks

Re: [Bro-Dev] libbroker status/plans

On Nov 3, 2014, at 3:50 PM, Robin Sommer ro...@icir.org wrote: When I tried compiling Broker with clang 3.5 (and it's libc++) the other day I got some compiler errors. I'll look more closely later, but was wondering what compiler are you using for development? $ c++ --version Apple LLVM

[Bro-Dev] ninja builds

Ninja builds (https://martine.github.io/ninja/) should now work with Bro’s master branch. After installing it, Bro can use it like: ./configure --generator=Ninja cd build ninja # May want to use —builddir if you want generated files to go somewhere besides ./build The

Re: [Bro-Dev] osquery integration

+- On the osquery side, we need to assemble the event for sending + to Broker. Generally, the columns returned by the ``SELECT`` + will turn into the event's arguments. In addition, we add an + always-present ``h: Host`` argument. The event arguments' types + need to

Re: [Bro-Dev] osquery integration

On Feb 4, 2015, at 11:02 AM, Robin Sommer ro...@icir.org wrote: It could also be part of the osquery side initially, and we'd move it over later if demand turns out to be there. That’s more what I was thinking. Either way doesn’t seem like a huge deal to me: don’t expect the code involved

Re: [Bro-Dev] Runtime increases

On Jan 16, 2015, at 5:39 PM, Robin Sommer ro...@icir.org wrote: When I measured timing differences caused by adding file reassembly, it was usually around +1%. Do you understand where that increase is coming from? Is it indeed because Bro is doing additional reassembly work now? In other

Re: [Bro-Dev] [Bro-Commits] [git/bro] topic/jsiwek/socks-authentication: Refactor SOCKS5 user/pass authentication support. (961fd06)

On Feb 12, 2015, at 7:24 PM, Seth Hall s...@icir.org wrote: On Feb 12, 2015, at 6:06 PM, Jonathan Siwek jsi...@ncsa.illinois.edu wrote: -event socks_login_reply%(c: connection, code: count%); +event socks_login_userpass_reply%(c: connection, code: count%); Did you find evidence that

Re: [Bro-Dev] Compiling Bro on RedHat, CentOs 6 and earlier (cmake)

On Feb 17, 2015, at 2:48 PM, Johanna Amann joha...@icir.org wrote: currently it is not possible to build Bro on RedHat / CentOs 6 or earlier because the cmake version available on those systems is too low. I think 6.6 has CMake 2.8.12.2 now. But yeah, before they were at 2.6.4. Is there

Re: [Bro-Dev] Compiling Bro on RedHat, CentOs 6 and earlier (cmake)

On Feb 17, 2015, at 4:58 PM, Johanna Amann joha...@icir.org wrote: Just to check - is removing the dependency for 2.8 as easy as changing the minimal cmake version and removing a few lines from one of the cmake scripts? Because in that case I would be tempted to just automatically patch it

Re: [Bro-Dev] Compiling Bro on RedHat, CentOs 6 and earlier (cmake)

On Feb 18, 2015, at 1:17 PM, Johanna Amann joha...@icir.org wrote: Thank you, that worked. One more question - currently Bro does not compile on systems that use libpcap 1.1.1, because PCAP_NETMASK_UNKNOWN is not defined (example compile error:

[Bro-Dev] switch to requiring CMake 2.8+ for Bro 2.4 ?

Doing a quick survey of what the major platforms offer, I found EL 6.6: CMake 2.8.12 Ubuntu 14.04 LTS: CMake 2.8.7 Debian 7.0: CMake 2.8.9 FreeBSD 9.3: CMake 2.8.12 Bumping up to requiring 2.8 would allow use of generator expressions. I’d be able to use that to properly fix the CMake policy

Re: [Bro-Dev] [Bro-Commits] [git/bro] topic/seth/more-file-type-ident-fixes: Lots of fixes for file type identification. (ee3e885)

On Mar 13, 2015, at 9:14 PM, Seth Hall s...@icir.org wrote: - Plain text now identified with BOMs for UTF8,16,32 (even though 16 and 32 wouldn't get identified as plain text, oh-well) Maybe it’s good/correct to identify UTF8,16,32 as associated w/ a main type of “text”, but a bit

Re: [Bro-Dev] libcurl and libev integration

On May 7, 2015, at 1:24 PM, lauri lauri.vosa...@gmail.com wrote: My conclusion at this very early stage is that it would make sense to substitute Bro's event loop and DNS client with libev. I’d also vote to investigate changing over to libev (or libuv since you mention it) and I also

Re: [Bro-Dev] Find filtered traces?

On Jun 22, 2015, at 3:50 PM, Seth Hall s...@icir.org wrote: I’ve been noticing this message... 1232039469.548925 warning in ~/bro/scripts/base/misc/find-filtered-trace.bro, line 48: The analyzed trace file was determined to contain only TCP control packets, which may indicate it's been

Re: [Bro-Dev] some Broker questions

On Jun 3, 2015, at 5:01 PM, Aashish Sharma asha...@lbl.gov wrote: 1) I see that stores-listener.bro has clone created into it and store-connector.bro has master in it. Does that mean the idea is to have workers run listener and manager run connector ? Which fundamentally means manager

Re: [Bro-Dev] Broker code question

> On Dec 14, 2015, at 5:23 PM, Robin Sommer wrote: > > Broker generates these two events in Bro: > >event BrokerComm::outgoing_connection_established(peer_address: string, > peer_port: port, >

Re: [Bro-Dev] CBAN naming

> On Jun 4, 2016, at 11:27 AM, Slagell, Adam J wrote: > > I still strongly disagree with ALL metadata being optional, unless it is > automatically cleaned up if they never “finish” putting in required data. Sorry, I was just talking about in terms of interoperability w/

Re: [Bro-Dev] CBAN naming

> On Jun 2, 2016, at 3:13 PM, Slagell, Adam J wrote: > > It looks like that term is just used here for “Script packages” and on all > the auto generated subpages. We can just rename that as I don’t it is not a > widely used term. I do want to do that before 2.5 if we do

Re: [Bro-Dev] CBAN naming

> On Jun 4, 2016, at 1:09 PM, Robin Sommer wrote: > > I really don't like calling these things "plugins", nor calling the > whole thing the "plugin manager". I'm with Jan here: I think that > would be quite misleading in terms of what I believe people associate > with "plugin”

Re: [Bro-Dev] CBAN naming

> On Jun 4, 2016, at 1:40 PM, Jan Grashöfer wrote: > > find a new name for the same thing. 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

Re: [Bro-Dev] CBAN naming

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

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

> On Jun 7, 2016, at 12:55 PM, Siwek, Jon <jsi...@illinois.edu> wrote: > > I’d appreciate if anyone would think a bit about whether “package” still > actually makes sense to use in the current context and doesn’t actually need > a rename. I can always repose this late

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

> On Jun 8, 2016, at 5:32 PM, Matthias Vallentin wrote: > > One question though: what is the top-level container name? package > Do you equate > one package with one container, or does the plural "packages" signify > something more collection-ish? I see them as one to

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

> On Jun 6, 2016, at 4:55 PM, Robin Sommer wrote: > > On Mon, Jun 06, 2016 at 21:08 +, you wrote: > >> Similar to Daniel’s question, is there a one time setup the user does >> or they need to modify local.bro every time they install a new >> container? > > In this case I

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

> On Jun 6, 2016, at 1:50 PM, Robin Sommer wrote: > > - For shipping scripts: > >- We simply add to Bro's BROPATH. That means one > can now put "@load " into local.bro and Bro will look for > a __load__.bro inside the top-level container directory. That >

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

> On Jun 9, 2016, at 3:29 PM, Matthias Vallentin wrote: > > I'm not sure if I understand the -community suffix. The client bro-pkg > makes sense to me. But the first association I have with > bro-pkg-community is a community-version of bro-pkg (i.e., the client). Was mostly

Re: [Bro-Dev] CBAN naming

> On Jun 3, 2016, at 2:39 PM, Slagell, Adam J wrote: > > So what would you do, call it the tool bro-bpm, the project “Bro Plugin > Manager” (BPM), and the objects being managed plugins? Yeah both the tool and the project are "Bro Plugin Manager” (or some variant of BPM

Re: [Bro-Dev] CBAN naming

> On Jun 3, 2016, at 2:48 PM, Thayer, Daniel N wrote: > > I like this idea better than anything else I've heard so far, but > one small issue is we would need to be a bit careful to distinguish between > "Bro plugins" (as seen by running "bro -N"), and > "Bro plugin

Re: [Bro-Dev] CBAN naming

> On Jun 4, 2016, at 4:27 AM, Jan Grashöfer wrote: > > From my perspective scripts do not extend Bro. Scripts get executed by > Bro to provide extended functionality. Calling Bro-scripts plugins for > Bro is somehow like calling python-scripts plugins for the python >

Re: [Bro-Dev] CBAN design proposal

> On May 24, 2016, at 2:52 PM, Jan Grashöfer wrote: > > > Imagine there was someone who published an awesome script but a new > version of Bro breaks it. Another one patched the script and sends the > patch to the original author. What will happen, in case he does not

Re: [Bro-Dev] CBAN design proposal

Here’s a revised/alternate design based on feedback so far: https://www.bro.org/development/projects/cban3.html Note that I put these at unique URLs and didn’t update in place since they’re different enough that, if someone tried to follow along from the start of the thread, I didn’t think it

Re: [Bro-Dev] CBAN naming

> On Jun 5, 2016, at 11:51 AM, Slagell, Adam J wrote: > > Regardless, it seems that you and Jon have irreconcilable differences that > eliminate plugin or package. And as the PI and implementer, I give high > weight to both of your opinions. Would either of you object to

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

> On Jun 6, 2016, at 10:46 PM, Robin Sommer wrote: > > So sounds like this proposal is something you can agree with? Yes. > > On Tue, Jun 07, 2016 at 02:01 +, you wrote: > >> So scripts do not autoload, but plugins do? > > Thinking more about that I would answer: yes.

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

> On Jun 7, 2016, at 9:32 AM, Azoff, Justin S wrote: > > So, the way this could work is that '$TOOL install foo' could both 'install' > and 'enable' 'foo' and '$TOOL disable foo' could disable it without removing > it. Yeah, that’s what I was thinking people would

Re: [Bro-Dev] CBAN naming

> On May 30, 2016, at 9:44 PM, Matthias Vallentin wrote: > > I don't know :-). We need a command line client and a project name. When > they are the same, it's certainly easier to remember. Yes, I think the client and project name should be the same. From the other

Re: [Bro-Dev] CBAN design proposal

> On May 26, 2016, at 10:46 AM, Robin Sommer wrote: > > - Let's keep BroControl integration in mind at leat. I agree that a > standalone client makes most sense right now, but if there's > something we can do that will make it easier for BroControl later to > integrate,

Re: [Bro-Dev] CBAN design proposal

> On May 26, 2016, at 11:14 PM, Robin Sommer wrote: > >> Is it an important use case for the client to be able to interact w/ >> other repos that are structured like the one the Bro Team will be >> hosting? Seems less likely that people will want to do that >> especially if the

Re: [Bro-Dev] CBAN design proposal

> On May 26, 2016, at 4:07 PM, Matthias Vallentin wrote: > > How do submodules scale? Or asked differently, what are the number > (order of magnitude) of submodules we're expecting? I imagine it will scale because when a user clones the main/parent CBAN repo, we’re telling

Re: [Bro-Dev] CBAN naming

> On Jun 1, 2016, at 5:30 PM, Slagell, Adam J wrote: > > These are variants of #1, which I now substitute with bro-pkg 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

Re: [Bro-Dev] get_event_peer() with Broker

> On Feb 1, 2016, at 4:45 PM, Robin Sommer wrote: > > I was looking at how to extend the get_event_peer() bif to work with > Broker events and realized that there's problem I hadn't thought about > so far: when a event comes into Bro through Broker, there's no way > right now to

Re: [Bro-Dev] Coding style enforcement

> On Mar 16, 2016, at 11:26 AM, Robin Sommer wrote: > > As I had mentioned to Matthias already, I don't have strong feelings > regarding Broker coding style. Changing that to match CAF sounds > reasonable to me, as a lot of the code's structure is driven by CAF as > well. Jon is

Re: [Bro-Dev] Broker & CAF includes

> On Mar 21, 2016, at 12:36 PM, Matthias Vallentin wrote: > > The "implementation detail" maxim lead to artifacts like PIMPL. This > certainly made sense at the time where we considered multiple messaging > backends. At this point, we are invested into CAF, and I don't think

Re: [Bro-Dev] Broker & CAF includes

> On Mar 18, 2016, at 10:20 PM, Matthias Vallentin wrote: > > During Broker refactoring, I noticed the following: all headers in > broker/* include either standard library headers or Broker headers. This > appears to be by design, which makes sense to me. > > As a library

Re: [Bro-Dev] Broker: use of broker::peering

> On Mar 31, 2016, at 11:00 PM, Matthias Vallentin wrote: > > In Broker, what is the use case for having an explicit peering between > two endpoints? Would it maybe suffice to provide endpoint introspection, > i.e., the ability to iterate over an endpoint's peers? I don’t

Re: [Bro-Dev] Broker & CAF includes

> On Mar 25, 2016, at 11:16 AM, Matthias Vallentin wrote: > > At this point, I'm inclined to move towards a more light-weight model > that is less robust against ABI changes. I believe we still need more > experience with the API. Once the API matures, hiding central >

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

Re: [Bro-Dev] CBAN design proposal

> On May 23, 2016, at 4:59 PM, Robin Sommer wrote: > >> 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

Re: [Bro-Dev] CBAN design proposal

> On May 23, 2016, at 6:30 PM, Slagell, Adam J wrote: > > 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

Re: [Bro-Dev] CBAN design proposal

> On May 24, 2016, at 11:49 AM, Slagell, Adam J wrote: > > I propose that we keep mandatory checks minimal, but not non-existent, and > then we reevaluate when we have real data about how well this works. But I > would really like more feedback from the community. Maybe

Re: [Bro-Dev] CBAN design proposal

> On May 25, 2016, at 12:12 AM, Robin Sommer wrote: > >> - discoverability metadata is aggregated during the nightly quality >> check processes and automatically commits that information to the >> “bro/cban” repo. > > Would it be better to maintain this information outside of

Re: [Bro-Dev] CBAN design proposal

> On May 24, 2016, at 4:46 PM, Matthias Vallentin wrote: > > More generally, there will presumably some functionality to add > "remotes" to one's configuration, allowing plugin writers to point to > experimental code if they wish. Then they can still hack out code and > mix

Re: [Bro-Dev] CBAN design proposal

> On May 25, 2016, at 9:49 AM, Slagell, Adam J wrote: > > So this has become an involved thread. Do we need a call, or do you think you > can pull out enough to get started Jon? Yes I can reorganize all latest ideas into an alternate design document. Or if you meant

Re: [Bro-Dev] package manager progress

> On Jul 25, 2016, at 10:18 AM, Matthias Vallentin wrote: > >> * Add a way for package’s to define “discoverability metadata”. >> >> E.g. following the original plan for this would involve putting >> something like a “tags” field in each package’s pkg.meta file, but the >>

Re: [Bro-Dev] package manager progress

> On Jul 27, 2016, at 11:15 AM, Johanna Amann wrote: > > And to add a me three to this - I am also with him on this one. On top > of things - I might misremember this, but didn't we plan package names > to include the github user name at one point of time? So a package name

Re: [Bro-Dev] package manager progress

> On Jul 27, 2016, at 12:59 PM, Robin Sommer wrote: > > Ah, I see. Would it be better to generally use the full path as the > name, and not search for submatches, to make it consistent/unambiguous > what a name refers to? At least from my usage it’s been convenient to be able

Re: [Bro-Dev] package manager progress

> On Jul 27, 2016, at 6:37 PM, Robin Sommer wrote: > > On the other hand, if, for example, somebody ends up > browsing the package source repository on GitHub, I'm sure they'd be > confused by all the packages pointing to very old versions. Yeah, agree that is confusing and a

[Bro-Dev] package manager progress

The package manager client is at a point now where I think it would be usable. Documentation is here: https://bro.github.io/package-manager/ There is a branch in the ‘bro’ repo called ‘package-manager’ that simply changes CMake scripts to install ‘bro-pkg’ along with bro. Here’s an example

Re: [Bro-Dev] package manager progress

> On Jul 28, 2016, at 3:37 PM, Robin Sommer wrote: > >> in favor of auto-installing the python dependencies into Bro’s install >> prefix. > > I also prefer auto-installation, unless there's a reasonable risk that > it could interfere with already installed versions of those

Re: [Bro-Dev] New documentation via Sphinx

> On Jul 27, 2016, at 11:22 PM, Matthias Vallentin wrote: > >http://bro.github.io/broker/ > > It's the bootstrap theme for sphinx, as an alternative to the classic > read-the-docs theme. I've hacked the sidebar so that it shows the table > of contents. I like that

Re: [Bro-Dev] package manager progress

> On Jul 25, 2016, at 6:53 AM, Jan Grashöfer wrote: > >> * Add a way for package’s to define “discoverability metadata”. >> >> E.g. following the original plan for this would involve putting something >> like a “tags” field in each package’s pkg.meta file, but the

Re: [Bro-Dev] package manager progress

> On Jul 25, 2016, at 10:31 PM, Matthias Vallentin wrote: > >> Right now, packages don’t get downloaded via the submodule, they are >> cloned directly from the package’s full git URL (which git just >> happens to encoded within the submodule). >> >> So this means only

[Bro-Dev] bro-pkg v0.3

Feedback from the previous bro-dev thread is now addressed and I’d consider this version of the package manager ready for people to start trying out. Documentation: http://bro-package-manager.readthedocs.io/ Notes/questions: * Docs are now hosted at Read the Docs instead of GitHub I found

Re: [Bro-Dev] package manager progress

> On Aug 5, 2016, at 1:29 PM, Slagell, Adam J wrote: > > If we are going to rely on metadata, which I agree can be better as you can > tag a package with multiple categories, we should probably have some basic > requirements for this type of metadata. At a minimum,

Re: [Bro-Dev] Broker data store API

> On Jul 22, 2016, at 2:26 PM, Matthias Vallentin wrote: > > - Does anyone use Broker's RocksDB backend? My recollection is that it was just nice-to-have an optional backend that users could choose, perhaps if they need better performance relative to SQLite. But I

Re: [Bro-Dev] bro-pkg v0.3

> On Aug 16, 2016, at 11:57 AM, Robin Sommer wrote: > > I think we need to state that more explicitly and > give some more context about this repo being the central hub for the > community to share scripts. Although not sure if the BPM docs are > actually the right place for

Re: [Bro-Dev] bro-pkg v0.3

> On Aug 15, 2016, at 10:20 AM, Robin Sommer wrote: > > One suggestion for "Create a Package": I believe the text > doesn't really say anywhere yet explicitly that a plugin can contain > these three different things. Maybe add paragraph summarizing what > "package" actually

Re: [Bro-Dev] Broker's remote logging (BIT-1784)

> On Feb 6, 2017, at 10:43 AM, Robin Sommer wrote: > > I propose that for now we make Broker work like the current model, and > then we go from there. If we need more, we can add that later. The > less semantic differences we have between old and new communication, > the easier

Re: [Bro-Dev] Broker's remote logging (BIT-1784)

> On Jan 31, 2017, at 5:41 PM, Azoff, Justin S wrote: > >> I'm wondering if there's a reason that in the Broker case things >> *have* to be this way. Is there something that prevents the Broker >> manager from doing the same as the RemoteSerializer? > > Jon would know

[Bro-Dev] Improving Bro's main loop

Just starting a discussion to take inventory of the current problems with Bro’s main loop and ideas for how to improve it. Let’s begin with a list of issues (please comment if you have additions): (1) It uses select(), which is the worst polling mechanism. It has an upper limit on number of

Re: [Bro-Dev] Improving Bro's main loop

> On Feb 9, 2017, at 12:02 PM, Robin Sommer wrote: > >- We need to maintain some predictability in scheduling, in > particular with regarding to timing/timers. Bro's network time > time is, by definition, defined through I/O. My gut feeling is > that we need

Re: [Bro-Dev] Testing and Docs for Packages

> On Jan 15, 2017, at 4:49 PM, Jan Grashöfer wrote: > > In general I think, making test cases available for users of a package > could be quite helpful. Further, I think we have also already mentioned > the possibility of compatibility checking regarding the installed

Re: [Bro-Dev] Testing and Docs for Packages

>> 1) Add `bro-pkg test ` command. > > Might it also make sense to just run the test on installation, before the > package is actually installed, to see if it works on the environment of > the user? Yes, I like that idea. (I’d also want a flag or config option to opt-out of that behavior). >

Re: [Bro-Dev] Testing and Docs for Packages

> On Jan 18, 2017, at 10:28 AM, Robin Sommer wrote: > > I also think it would be quite useful to test packages before > installing them Maybe I’m not so much questioning whether to run tests before or after installation, but rather if the testing sandbox should include

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

Either way seems fine to me also. Maybe do a strawpoll and go w/ the majority. Other misc. thoughts: Internally, I already used “bropkg” instead of “bro-pkg” for the name of the Python package/API because Python discourages use of hyphens in module/package names. But using the Python API

Re: [Bro-Dev] Proposal: Operating the Bro package manager offline

> On Sep 21, 2016, at 9:54 AM, Robin Sommer wrote: > > What are the default paths? In other words, where do the downloaded > packages get put if I don't set anything further up? They get put within ~/.bro-pkg/ (The Advanced Configuration [1] section has more usage info related

Re: [Bro-Dev] Proposal: Operating the Bro package manager offline

> On Sep 19, 2016, at 6:27 PM, Robin Sommer wrote: > > @Jon: Do you think this would be doable that way? Yeah, looks viable. > - I’m not quite sure if the bundle should contain just the packages > themselves or further bro-pkg state as well, such as which packages > are

Re: [Bro-Dev] Proposal: Operating the Bro package manager offline

> On Sep 19, 2016, at 11:11 PM, Azoff, Justin S wrote: > > Sounds great.. What you are describing is basically source and binary > packages. In concept, I like the idea of simply extending the “install” command to be able to install from a source or binary packages, but

Re: [Bro-Dev] Blog post for bro-pkg

Yeah, I can write a blog post. - Jon > On Sep 23, 2016, at 1:58 PM, Slagell, Adam J wrote: > > 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

Re: [Bro-Dev] Package manager meta data

> On Oct 28, 2016, at 5:52 PM, Jan Grashöfer wrote: > > Correct me if I am wrong > but bro-pkg.meta contains stuff like script_dir and dependencies (so > rather technically), whereas bro-pkg.index contains the descriptive > information like info text and tags (which is

Re: [Bro-Dev] Package manager meta data

> On Nov 21, 2016, at 10:38 AM, Robin Sommer wrote: > > On Mon, Nov 21, 2016 at 15:53 +, you wrote: > >> When selecting a version, `bro-pkg update` only considers newer x.y.z >> release tags for that package. When selecting a branch, it tracks >> updates along that branch.

Re: [Bro-Dev] Package manager meta data

Here’s a summary of the set of changes I plan to make related to package metadata, let me know if there’s objections or alternate ideas: 1) remove mentions of ‘version' field from bro-pkg.meta as versioning is done entirely by git tags 2) packages should now put ‘description’ and ‘tags' fields

Re: [Bro-Dev] Package manager meta data

> On Nov 20, 2016, at 1:57 PM, Robin Sommer wrote: > > What will be the relationship between version tags and the master > branch? Is master just another version I can select to install? Yes, any tag or branch can be selected with `bro-pkg install —version `. When selecting a

  1   2   >