[Bro-Dev] Serialization type of internal data structures

I am in the process of making a bit vector class serializable, but this class does not directly correspond to a value at script land, rather, Bloom filters will use this data structure internally. Making a class serializable involves adding a new unique identifier in SerialTypes.h. However, I am

[Bro-Dev] Bloom filter interface

I'm the process of devising Bro's new Bloom filter interface and would like to have your feedback on the BiFs. This is what I came up with so far: (1) bloomfilter_init(fp: double, capacity: count, max: count): opaque of bloomfilter (2) bloomfilter_add(bf: opaque of bloomfilter, x: any) (3)

Re: [Bro-Dev] Bloom filter interface

So it sounds like having the merge function returning bool was an accident? Exactly, well-spotted! Matthias ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] [Bro-Commits] [git/bro] topic/matthias/bloom-filter: Fixing for unserializion error. (40201a1)

Fixing for unserializion error. Thanks for delving into it! Because BloomFilter is a base class, with other classes derived from it, it needs special treatment. I assume this is only necessary when serializing through the base class? For example, we have another serializable base

Re: [Bro-Dev] Time for C++11?

I'm guessing (and hearing :-) that most of us would like to start using C++11 in Bro's code base. With compiler support now apparently broad and robust, and our 2.4 dev cycle starting, I'm thinking it may be a good time now to make the move. I would go one step further: let's aim for C++14.

Re: [Bro-Dev] Time for C++11?

I would go one step further: let's aim for C++14. I was expecting you to propose that. :-) And I knew your answer beforehand :-). I'm very reluctant to rely on a cutting-edge compiler for compiling Bro. There's really not much worse for an open-source tool than downloading the code and

[Bro-Dev] Pattern matching for the Bro language

TL;DR: function f() : any; local result = ; switch( f() ) { case addr: if ( x in 10.0.0.0/8 ) result = got it!; case string: result = f() failed: + x; } I want to propose introducing pattern matching for the Bro language. Pattern

Re: [Bro-Dev] Pattern matching for the Bro language

local result = switch( x ) { case T: case U: }; Personally, this strike me as a tad weird, since now result might not have a statically determined type, so we're back to it being any. To avoid falling back to any land, the additional constraint

Re: [Bro-Dev] CBAN naming

> 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." This would be the name for the command line client. How would we call the whole thing? The Bro

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

> project name: Bro Package Manager > client name: bro-pkg > git repo name: bro-pkg > design spec/proposal: use Robin's/Johanna’s > top-level container name: packages > changes to existing naming conventions: none Looks good to me. One question though: what is the top-level container name? Do

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

> I see benefits in two separate repos: Yep. > client: bro-pkg > community packages: bro-pkg-community 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

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

> > Do you equate one package with one container, or does the plural > > "packages" signify something more collection-ish? > > I see them as one to one. Okay, that's what I was thinking as well. Matthias ___ bro-dev mailing list bro-dev@bro.org

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

> I like the “packages” + “package-manager” combo that Johanna suggests. +1 Matthias ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] CBAN naming

> I like how Spicy was named, by choosing something completely different and > unrelated to the "bro" theme. I like that too. Do you have a suggestion? Matthias ___ bro-dev mailing list bro-dev@bro.org

Re: [Bro-Dev] CBAN naming

> Besides naming and skipping ahead to implementation, I highly recommend > looking at how Rust manages crates. They are a pleasure to use and work > with. Rust's cargo [1] is indeed well thought through (I like the dependency specification especially [2]) and we should look at it in depth during

Re: [Bro-Dev] CBAN naming

> By the way: Are we talking about renaming the whole project? 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. My favorite name so far is also "brow." The eye brow of the Bro logo makes for a nice association. It

Re: [Bro-Dev] CBAN naming

> - boxer, boxes (sort of already taken by Broala's BroBox) > - bundler, bundles (though seems like Ruby has taken this name) > - bagger/bagboy, bags (also has the association w/ eye bags) > - tempest, drops (eye of the storm, rain drops, eye drops... the tears of > those trapped

[Bro-Dev] CBAN naming

To find the new name for our CBAN project, it probably make sense to brainstorm separately from the existing technical thread. I'd say let's collect some candidates and then create survey to vote on them. Here are some ideas from the existing thread: - brow - broil - broom - bpk

Re: [Bro-Dev] Broker status update

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

Re: [Bro-Dev] CBAN design proposal

> - having both "upgrade" vs "update" commands sounds confusing, I'm > sure I would constantly mix up the two. Suggest to rename one of > them. I think this comes from Homebrew (and maybe other package managers as well). I kinda got used to it in this context, but occasionally still trip over

Re: [Bro-Dev] CBAN naming

> I like all these suggestions from Adam - and as a person who enjoys making > electronic music would humbly add 'bpm' (Bro Package Manager) to the list > ;-) We had a good discussion in the Bro Gitter channel about this yesterday. In fact, I suggested "bpm," but as it turns out, there exists

[Bro-Dev] Broker raw throughput

ngs, but I don't remember it being factor 5-6 worse. Thanks for sending me the gperf graphs. I will come back to you after running a test series under Linux and digging through the code a bit. Dominik ----- Forwarded message from Matthias Vallentin <vallen...@icir.org> - From: Matth

Re: [Bro-Dev] Broker updates?

> If there are updates to a Broker store, is there a way that I can get > evented notification that a key was modified? I'm not seeing anything > that provides that functionality yet, but I need it for something I'm > working on. That's currently not supported, but it's on the wish list [1].

Re: [Bro-Dev] Broker raw throughput

For better reproducibility, here's the Makefile that I used to drive the experiments: CC = cc CXX = c++ FLAGS = -O3 -g -std=c++11 -stdlib=libc++ LIBS = -lcaf_core -lcaf_io -ltcmalloc -lprofiler caf-client: caf-client.cpp $(CXX) $(FLAGS) $< -o $@ $(LIBS)

Re: [Bro-Dev] Broker raw throughput

> The optimization I meant is to not wrap each integer in its own > message object, but rather make one message which then contains X > integers that are transparently interpreted by the receiver as X > messages. But this requires some form of "output queue" or lookahead > mechanism. I can see

[Bro-Dev] Broker & CAF includes

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 writer, one faces the tricky question of exposing headers from dependencies. For example,

[Bro-Dev] Coding style enforcement

While porting Broker to the latest CAF version, I am realizing that the current pre C++11 coding style is not very conducive. Since the introduction of lambdas, and in particular with CAF's asynchronous and template-heavy programming model, the Whitesmiths style isn't very practical. Once can

Re: [Bro-Dev] Fw: Broker raw throughput

> To me, the performance numbers themselves don't matter as much as > managing expectations does: should I *expect* to be able to pass all > of my events through broker? This question depends on the event type and your concrete topology, and is hard to answer in general. We can say "in our

Re: [Bro-Dev] Coding style enforcement

> I’m fine w/ any style or naming convention changes in order to cause > less friction for Matthias/others. Good to know Jon, thanks for chiming in. My goal is to leverage clang-format to the best degree possible such switching styles is not a big undertaking. Since no tool has (yet) good

Re: [Bro-Dev] Broker & CAF includes

> Providing stable-ish ABIs seems like something libraries often do, so > I tried to plan that in to Broker. Don’t know if I did that well, or > there’s better strategies to use, or I was the only one worried about > that to begin with, but thought I’d mention it just in case it wasn’t > even on

Re: [Bro-Dev] Broker & CAF includes

Thanks for chiming in, Jon. > [..] i.e. treat the use of CAF an implementation detail. This is the clean way to think about layering and creating abstractions. It applies to the API perspective, though. As long as CAF internals are hidden from a Broker user, we are good. The "implementation

Re: [Bro-Dev] Broker raw throughput

> @Matthias: FYI, I have used a new feature in CAF that allows senders > to get feedback from the I/O layer for not overloading it. This allows > the sender to adapt to the send rate of the network. Great, it sounds like this would fix the stall/hang issues. I expect to port Broker to the

Re: [Bro-Dev] Broker raw throughput

> I have created a ticket for further progress tracking / discussion [1] > as this is clearly not a Bro/Broker problem. Thank you all for > reporting this and all the input you have provided. It's good to see the new commit improves performance. But I want to take again the perspective of Broker,

Re: [Bro-Dev] Broker raw throughput

> You could additionally try to tweak > caf#middleman.max_consecutive_reads, which configures how many > new_data_msg messages a broker receives from the backend in a single > shot. It makes sense to have the two separated, because one configures > fairness in the scheduling and the other fairness

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

> I think you’re safe changing it as long as a user continues to have a > way to disconnect an endpoint from any one of its peers. Yep, that makes sense. Thanks for chiming in. Matthias ___ bro-dev mailing list bro-dev@bro.org

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

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? At least Bro doesn't use broker::endpoint for anything but that, but I was wondering if I am

[Bro-Dev] Broker status update

This is just a brief summary of where the Broker overhaul is currently at. The new Broker API will come two types of endpoints: blocking and nonblocking. The former provides a synchronous API to receive messages, whereas the latter operates fully asynchronous. Performance-wise, the asynchronous

Re: [Bro-Dev] Broker C++ namespace: broker -> bro?

> Not sure I like that. The library is called Broker, so "broker" seems > the natural namespace to me. All right, let's keep it as is. This is also aligns with the sentiment at our Gitter room. > I think the better solution would be finding a different name for > those things now called

Re: [Bro-Dev] bloomfilter_counting_init parameterization ?

> global bloomfilter_counting_init: function(k: count , cells: count , > max: count , name: string =""): opaque of bloomfilter ; The counting Bloomfilter is very similar to a regular Bloom filter, except that the underlying bit vector now consists of "cells," i.e., sequences of bits that

Re: [Bro-Dev] CBAN design proposal

(I will respond to the actual proposal in more depth later.) > That is a good point. I am more concerned about accumulating clutter. 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

Re: [Bro-Dev] package manager progress

> 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 packages a user is interested in end up getting > downloaded. I'm not 100% following. Isn't

Re: [Bro-Dev] package manager progress

> > I'm not 100% following. Isn't every package recorded as submodule? > > Every package within a package source is recorded as a git submodule > and that recording happens at the time the package author registers > their package with a source. The bro-pkg client itself makes no > changes to

Re: [Bro-Dev] Some thoughts on the bro deep cluster, broker, and sumstats

> *tl;dr* Just a quick heads-up: thanks a bunch for summarizing your thoughts! We haven't forgotten your mail and will get back after we're done with our crunch with releasing Bro 2.5. Stay tuned, Matthias ___ bro-dev mailing list bro-dev@bro.org

[Bro-Dev] Broker data store API

TL;DR: - Does anyone use Broker's RocksDB backend? - Brief overview of the revamped data store frontend API I've been working on the Broker data store API a bit, trying to come with the smallest denominator possible for an initial release. So far I have ported the in-memory SQLite backend

Re: [Bro-Dev] Broker data store API

> I can't speak to whether or not it is 'needed', but I have had desire > to use it in the past... The only thing preventing me from doing it > was the fact that Broker is currently a fast moving target. Good to know. Scott Campbell also uses the current version of Broker in his projects and

Re: [Bro-Dev] package manager progress

> The package manager client is at a point now where I think it would be > usable. Cool! > * 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

Re: [Bro-Dev] package manager progress

> I actually don't like this that much because some of these can cross > boundaries and do all sorts of different things in a single plugin. > It makes more sense to me to leave the naming open. I'm with Seth on this one. The reason why I think we should keep the naming open is that it's the

Re: [Bro-Dev] package manager progress

> - Would suggest to rename “pkg.meta” to, say, “bro-pkg.meta”, just to > make it more explicit that it's a Bro package. That's something one > can also then search for on GitHub. Just throwing in two more permutations: bro.meta or bro.pkg. > - For our default package source, do we want to

[Bro-Dev] New documentation via Sphinx

I'm in the process of documenting Broker with Sphinx. With minimal effort, I put up a scaffold that looks like this: 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

[Bro-Dev] [Broker] multi-topic subscriptions

If a broker endpoint subscribes to multiple topics, how many messages do you expect to receive? Consider this snippet: context ctx; auto e = ctx.spawn(); e.subscribe("/foo"); e.subscribe("/foo/bar"); e.subscribe("/foo/bar/baz"); e.publish("/foo/bar/baz", 4.2); Should the endpoint

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

> 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? Some background: when Broker sends to a log topic, the message has the structure of a pair (id, (x, y, z,

Re: [Bro-Dev] Scaling out bro cluster communication

> What I want to make possible is client side load balancing and > failover for worker -> manager/datanode communication. This is an important part of future Bro deployments. Before delving into script code, I would like to get a better understanding of the underlying concepts and communication

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

> 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 changes. Personally, I never had trouble typing "bro-pkg" though. Can we do a Twitter poll to figure out what our users prefer?

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

> I like Jon's idea to create a symlink for bro-pkg. One could also > install links for brocut and bro-ctl. PREFIX/bin/bro PREFIX/bin/bro-ctl PREFIX/bin/broctl PREFIX/bin/bro-cut PREFIX/bin/brocut PREFIX/bin/bro-pkg PREFIX/bin/bropkg .. That looks too confusing to

Re: [Bro-Dev] [Proposal] Language extensions for better Broker support

> Personally, I see this more as a question of readability (as opposed > to typeability :). But it's a matter of taste, and I'd be fine with > using "as" instead of "cast<>". Probably aligned with that thought is consistency and intuition: we don't have C++-style angle brackets in Bro, so "as"

Re: [Bro-Dev] [Proposal] Language extensions for better Broker support

> I might prefer just doing the unpacking myself. Having > separate/explicit checks for each individual return value would > naturally occur over time anyway (e.g. when debugging, adding extra > logging, improving error handling). > How common do you expect async function chains to occur? Any

Re: [Bro-Dev] [Proposal] Language extensions for better Broker support

> > local r = put(store, key, test(lookup(store, key))); > > For prototyping purposes, I see the convenience in that, but wonder if > the runtime will do something that’s useful and widely applicable > enough for that to translate directly into production code. What > exactly does the runtime

Re: [Bro-Dev] [Proposal] Language extensions for better Broker support

> I don't really like using a record like that, as that would associate > specific semantics with what's really a user-definable type. It was only meant to illustrate the idea of error handling and function composition. These ideas still hold up when substituting the user-defined result type

Re: [Bro-Dev] Rethinking Broker's blocking API

> > To distinguish between the two status, I use operator bool. > > I don't see that in the "status and error handling" section. Would I > do "if (! status) { }"? That doesn't seem quite > intuitive. I think a method with a descriptive name would be better > here. Sorry, that was misleading.

Re: [Bro-Dev] dynamic-cast branch (Re: [Bro-Commits] [git/bro] topic/robin/dynamic-cast: Add experimental "is" and "as" operators. (dabe125))

> So not sure what the right solution is but for now: either upgrade > bison, or remove the line and keep an eye on if things work correctly. Upgrading Bison worked just fine, thanks. Matthias ___ bro-dev mailing list bro-dev@bro.org

Re: [Bro-Dev] Rethinking Broker's blocking API

> Sorry, that was misleading. Statuses don't provide an operator bool. > They could, however, to distinguish them from errors. Mulling over this more, I'm not sure if it's clear which status codes constitute an error. For example, there's a peer_lost and peer_recovered status code. Is only the

Re: [Bro-Dev] Rethinking Broker's blocking API

> I see the challenge but I think we need some way to differentiate > serious errors from expected updates, otherwise we're back at writing > switch statements that need to comprehensively list all cases. I agree that writing switch statements is not very productive. From a user perspective,

Re: [Bro-Dev] [Proposal] Language extensions for better Broker support

> Feedback welcome, this is just a first draft. I like this. Some initial feedback: - In the switch statement, I would require that a user either provide a default case or fully enumerates all cases. Otherwise it's too easy to cause harder-to-debug run-time errors. - For the

Re: [Bro-Dev] Rethinking Broker's blocking API

> I think the name "error" is not just misleading but would also turn > out tricky to use correctly. Agreed. > auto msg = ep.receive(); > > if (msg) > return f(*msg); // unbox contained message > > if (msg.failed()) > cout << "Trouble: " << to_string(msg.status())

Re: [Bro-Dev] Rethinking Broker's blocking API

> Nice summary of the challenge! I agree that none of the options you > list sound really appealing. Here's an alternative idea: could we > change your option 1 (the variant) into always returning *both*, i.e., > tuple? You pushed me into a new direction. Broker already returns

Re: [Bro-Dev] [Proposal] Language extensions for better Broker support

> > [result, value] = Broker::lookup(h, 42) # Returns [Broker::Result, > > opaque of Broker::Data] > > > > if ( result == Broker::SUCCESS ) ... > > I would prefer this solution, as it feels more natural coming from other > languages like python. I like it as well because there's no

Re: [Bro-Dev] [Proposal] Language extensions for better Broker support

> Yeah, I agree, don't like that version anymore either. Ok, good. :-) > case type count as c: > > > > What do you think of that? The additional "type" makes it visually > clear what's it's about, and also helps the parser figure it out. I find that there's too much going on

Re: [Bro-Dev] [Proposal] Language extensions for better Broker support

On Wed, Dec 14, 2016 at 04:17:26PM +, Siwek, Jon wrote: > > > On Dec 13, 2016, at 11:42 AM, Matthias Vallentin <vallen...@icir.org> wrote: > > > >>> local r = put(store, key, test(lookup(store, key))); > > > > It's up to the user to check the

[Bro-Dev] Rethinking Broker's blocking API

Broker's current API to receive messages is as follows: context ctx; auto ep = ctx.spawn(); ep.receive([&](const topic& t, const data& x) { .. }); ep.receive([&](const status& s) { .. }); or the last two in one call: ep.receive( [&](const topic& t, const data& x) { ..

Re: [Bro-Dev] [Bro-Commits] [git/bro] topic/robin/dynamic-cast: Add experimental "is" and "as" operators. (dabe125)

> function check(a: any) > { > local s: string = "default"; > > if ( a is string ) > s = (a as string); Are the parenthesis around the expression required? Intuitively, operator "as" should have higher precedence. Matthias

Re: [Bro-Dev] Rethinking Broker's blocking API

> But not a big deal either way, any of these options sounds fine to me. This is the synopsis for the slightly adapted message class, no other changes: class message { public: /// Checks whether a message is a (topic, data) pair. /// @returns `true` iff the message contains a

Re: [Bro-Dev] Broker data layouts

> I don't really see a way around that without substantially increasing > volume. We could send LogCreate updates regularly, so that it's easier > to synchronize with an ongoing stream. It sounds like this is critical also for regular operation: (1) when an endpoint bootstraps slowly and the

Re: [Bro-Dev] Broker data layouts

> Agree. Right now a newly connecting peer gets a round of explicit > LogCreates, but that's probably not the best way forward for larger > topologies. Okay. In the future, we probably need some form of "serialization-free" batching mechanism to ship data more efficiently. There exist

[Bro-Dev] How to use Broker::Data in an event handler?

I'm trying to figure out if/how it is possible to use Broker::Data in an event handler as follows: event foo(x: Broker::Data) { print x; } I'm trying to send an event via the Python bindings: event = broker.bro.Event("foo", broker.Data(42))

[Bro-Dev] switch/case type recognition

Consider this snippet: function f(x: any) { switch (x) { case type any: print "any"; break; case type vector of any: print "vector of any"; break; } } event bro_init() { f(42); }

Re: [Bro-Dev] How to use Broker::Data in an event handler?

> This, plus a couple other bugs should now be fixed in bro + broker, so make sure to update both if trying the above examples. Great, it works now! One more question: how would I capture a default-constructed broker::Data() in a case statement? This would happen when I publish just "None" on

Re: [Bro-Dev] 'async' update and proposal

>I think we should instead just skip the "async" keyword altogether. >Requiring it at some places, but not others, hurts more than it helps >in my opinion. This sounds fine to me. Given that Bro is inherently an asynchronous language, it makes sense to for those semantics to trickle down to the

Re: [Bro-Dev] Module prefix in sending and receiving Broker events

Jan: > Event handlers just don't seem to inherit the surrounding module > namespace, which kind of makes sense if you want to handle events > generated in the global namespace. I agree that it does make sense in that regard. It's certainly prudent - as mentioned - to always qualify your events.

Re: [Bro-Dev] Module prefix in sending and receiving Broker events

ro script "foo". So far so good. If I remove the event declaration, the Python script prints [, , ['foo', []]] and the Bro script nothing. I hope this illustrates the issue a bit better. Matthias -- Matthias Vallentin CEO Tenzir GmbH c/o Regus Valentinskamp 24 20354 Hamburg i...@ten

[Bro-Dev] Module prefix in sending and receiving Broker events

When I receive events from Bro via Broker, they have the prefix of the enclosing module: module Foo; event foo() { ... } event bar() { ... } When I publish "foo" via Broker, it arrives as "Foo::foo". However, when I publish an event "Foo::bar" from Broker, Bro doesn't recognize

Re: [Bro-Dev] Module prefix in sending and receiving Broker events

> Does the > suggestion [1] to always explicitly scope events by their > namespace/module address your problem? That's what I thought would work, but it's the opposite: when I add the module name as prefix, Bro silently ignores the event. I found a surprising solution though: if I declare the

Re: [Bro-Dev] switch/case type recognition

> A 'vector of any' also qualifies as an 'any', so while the error > message of "duplicate case label" could possibly be improved, I think > it's still correct in that it is meant to prevent an ambiguous case > match. Yeah, with that reasoning anything qualifies as "any", so adding "any" should

Re: [Bro-Dev] How to use Broker::Data in an event handler?

> case type Broker::Data as d: > print "Broker::Data, expected to be nil", d?$data, d?$data ? > cat(d$data) : "nil"; > # or use the same logic from the is_nil() function above This is the logic I was looking for, thanks! The generic is_nil function might come in handy some

[Bro-Dev] [JIRA] (BIT-1057) topic/jsiwek/bloomfilter-fix

[ https://bro-tracker.atlassian.net/browse/BIT-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510#comment-13510 ] Matthias Vallentin commented on BIT-1057: - Yup, this looks good to me. For the record

[Bro-Dev] [JIRA] (BIT-1016) Option to extend uids to 128 bit

[ https://bro-tracker.atlassian.net/browse/BIT-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13810#comment-13810 ] Matthias Vallentin commented on BIT-1016: - Regarding performance: another option would

[Bro-Dev] [JIRA] (BIT-1073) Make the MIME analyzer a FAF analyzer

Matthias Vallentin created BIT-1073: --- Summary: Make the MIME analyzer a FAF analyzer Key: BIT-1073 URL: https://bro-tracker.atlassian.net/browse/BIT-1073 Project: Bro Issue Tracker Issue

[Bro-Dev] [JIRA] (TM-15) Segfault in FifoDisk.cc

Matthias Vallentin created TM-15: Summary: Segfault in FifoDisk.cc Key: TM-15 URL: https://bro-tracker.atlassian.net/browse/TM-15 Project: Time Machine Issue Type: Patch Affects Versions

[Bro-Dev] [JIRA] (BIT-1166) installation does not take place in given prefix entirely

[ https://bro-tracker.atlassian.net/browse/BIT-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Vallentin updated BIT-1166: Resolution: Cannot Reproduce Status: Closed (was: Open) installation does

[Bro-Dev] [JIRA] (BIT-1140) Bloomfilter hashing problem

[ https://bro-tracker.atlassian.net/browse/BIT-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Vallentin updated BIT-1140: Status: Merge Request (was: Open) Bloomfilter hashing problem

[Bro-Dev] [JIRA] (BIT-1140) Bloomfilter hashing problem

[ https://bro-tracker.atlassian.net/browse/BIT-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=16800#comment-16800 ] Matthias Vallentin commented on BIT-1140: - I could reproduce the issue with your

[Bro-Dev] [JIRA] (BIT-672) Bring POP3 back into the distribution

[ https://bro-tracker.atlassian.net/browse/BIT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20014#comment-20014 ] Matthias Vallentin commented on BIT-672: We had student refactoring the code, but his

[Bro-Dev] [JIRA] (BIT-1454) Merge request for topic/mfischer/broker-bugfixes

[ https://bro-tracker.atlassian.net/browse/BIT-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Vallentin reassigned BIT-1454: --- Assignee: Matthias Vallentin Merge request for topic/mfischer/broker-bugfixes

[Bro-Dev] [JIRA] (BIT-1454) Merge request for topic/mfischer/broker-bugfixes

[ https://bro-tracker.atlassian.net/browse/BIT-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Vallentin updated BIT-1454: Status: Closed (was: Merge Request) Good catch, thanks. Merge request for topic

[Bro-Dev] [JIRA] (BIT-1411) SQL_Injection_Victim is a misleading name

[ https://bro-tracker.atlassian.net/browse/BIT-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=21973#comment-21973 ] Matthias Vallentin commented on BIT-1411: - I like this syntax and the proposed semantics. I've created

[Bro-Dev] [JIRA] (BIT-1474) Improve signaling of deprecated code

Matthias Vallentin created BIT-1474: --- Summary: Improve signaling of deprecated code Key: BIT-1474 URL: https://bro-tracker.atlassian.net/browse/BIT-1474 Project: Bro Issue Tracker Issue

[Bro-Dev] [JIRA] (BIT-1411) SQL_Injection_Victim is a misleading name

[ https://bro-tracker.atlassian.net/browse/BIT-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=21971#comment-21971 ] Matthias Vallentin commented on BIT-1411: - {quote} There needs to be some model of deprecating

[Bro-Dev] [JIRA] (BIT-1474) Improve signaling of deprecated code

[ https://bro-tracker.atlassian.net/browse/BIT-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=22009#comment-22009 ] Matthias Vallentin commented on BIT-1474: - Ah, I missed that. That's definitely something we can work

[Bro-Dev] [JIRA] (BIT-1506) Bro fails to build on OS X 10.11 (El Capitan) due to OpenSSL header removal

[ https://bro-tracker.atlassian.net/browse/BIT-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25701#comment-25701 ] Matthias Vallentin commented on BIT-1506: - Right, ideally we avoid a new release, because it's

[Bro-Dev] [JIRA] (BIT-1506) Bro fails to build on OS X 10.11 (El Capitan) due to OpenSSL header removal

[ https://bro-tracker.atlassian.net/browse/BIT-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25604#comment-25604 ] Matthias Vallentin commented on BIT-1506: - This looks like the right way to search for OpenSSL under

[Bro-Dev] [JIRA] (BIT-1558) Bro's ascii formatter writing out scientific notation

[ https://bro-tracker.atlassian.net/browse/BIT-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25102#comment-25102 ] Matthias Vallentin commented on BIT-1558: - Looks like a missing `std::fixed` in an I/O stream

  1   2   >