____
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
emember those discussions we had about &log back then and I
remember being the one that pushed for it but even then I didn't feel
particularly comfortable with it (as I recall you feeling).
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
http://blog.bro.org/2018/10/renaming-bro-project_11.html
Thanks for writing the uap plugin!
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
> On Mar 9, 2018, at 12:55 AM, Vitaly Repin wrote:
>
> Hello,
>
> I would like to bring your attention to one strange and unexpecte
ncourage people to refer to fields by the field name rather
than the ordinal position of the field.
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Thanks Vlad!
.Seth
On 16 Jun 2018, at 9:07, Vlad Grigorescu wrote:
> Yep, already working on it. :-)
>
> On Sat, Jun 16, 2018 at 6:26 AM, Seth Hall wrote:
>
>>
>> On 15 Jun 2018, at 17:22, Azoff, Justin S wrote:
>>
>>> The fix is a little trickier, y
Bro has re-reached the point where
touching any number of things can set off an avalanche of problems like
this.
Anyone on this thread up for submitting a patch which makes Bro cope
with the changes automatically? You can then even mark the old events
as deprecated. :)
.Seth
-
On 15 Jun 2018, at 20:02, Michał Purzyński wrote:
> Hey, I use the dhcp analyzer because i cannot count on our dhcp logs.
> Not just that, I do some detection around it.
How much trouble is it to migrate your scripts to what's in Bro master?
.Seth
--
Seth Hall * Cor
note in the release to say that
developers will need to handle a new event to get the data. On the
upside, you can handle both the old events and the new and they
shouldn't impact each other (if you want to make a script work on
multiple releases).
.S
t sure if we'd be able to do all of the git work from that though.
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
int but now I can't wait
for you to be able to turn your attention to other stuff soon. :)
Thanks!
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
second so
you see Bro's clock driven forward in very tiny increments as you would
expect. If you go a long time without receiving a packet is when stuff
gets tricky.
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing
(c) smb_cmd.log
(d) smb_files.log
(e) files.log
(f) conn.log
(g) packet_filter.log
Not sure what is going wrong. Please help.
Cheers,
Mark
___
bro-dev mailing list
bro-dev@bro.org
h
ly be willing to receive up to the 1000 most recent message or up to
1MByte of data.
I still haven't spent time with the broker API to see if these thoughts
actually make sense though. :)
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
__
oncerned about
the difficulty of building Bro from source too.
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
/or a way to know that the client has not sent any data on
> the connection (like an equivalent of the `seq` parameter, but for the
> `ack`)?
>
> Also, when `seq` equals 1, am I certain that I have not missed any
> packet from the server?
>
> One more question: is there a better, cleaner, etc. way to do what I'm
> trying to do?
>
> Thanks a lot,
>
> Pierre
>
> --
> Pierre
> http://pierre.droids-corp.org/
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
;
> Cheers,
> Mark
>
> -Original Message-
> From: Seth Hall [mailto:s...@corelight.com]
> Sent: Saturday, February 3, 2018 10:46 PM
> To: Fernandez, Mark I
> Cc: bro-dev@bro.org
> Subject: Re: [Bro-Dev] Bro DCE-RPC Fix for AlterContext and
> AlterContextResponse Parsers
&
o submit the changes along with tests.
Thanks,
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
existed with either of your outlined implementations I don't
think we could resist merging it in. ;)
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
___
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
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
> Johanna
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
e if we went
that direction though? It seems like it could cause trouble by causing
events to backup waiting for some other event to finish executing.
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@
Thanks Jon! I do apologize Jeffrey, the pull request was my responsibility and
I've been meaning to get to it.
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
> On Jan 2, 2018, at 11:58 AM, Jon Siwek wrote:
>
> On Fri, Dec 29, 2017 at 2:19 AM, Bencteux Jeffrey
>
ing
> the
> current behavior.
Ah, I like that idea. I think the current logs (both JSON formatted and
normal Bro format) are fine for most people, but for the people that
actually want doubles displayed differently this could give them that
option.
.Seth
--
Seth Hall * Coreligh
k and they all support scientific notation (I think that
was part of my concern a long time ago).
Thoughts?
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/lis
Some of these changes sound like they could take a
while to prototype and figure out how they would be effectively used.
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ore.
Woohoo! It's getting closer. :)
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
bro-pkg install bro/bro-netmap
You can read some more directions about how to use it in the repository
here:
https://github.com/bro/bro-netmap
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
On 22 Sep 2017, at 16:26, Jan Grashöfer wrote:
>> module Foo;
>>
>> export {
>>
>> ## The username for our new feature.
>> ##
>> ## Display: User Name
>> option user_name: string;
>>
>> }
>
> I really like tha
or instance, has a types tab which documents the names
>> of
>> the parameters, and what they do:
>> https://forge.puppet.com/puppetlabs/mysql/types This would be pretty
>> easy
>> to do with the Broxygen documentation, and a UI could also expose
>> this.
>
owing "Username".
Sometimes abstraction like this isn't warranted, but I think it has to
be done here. Bro needs to turn into a platform that treats users as
first class citizens in the community and we need to acknowledge that
there will be a day that they won't be reading scrip
long and explanatory but may not end up
being just right if someone simply wants to configure a behavior.
There's also the problem of single level namespaces which will limit the
expressiveness and depth that you could possibly give through
configuration keys.
.Seth
--
Seth Hall * C
ably in most cases just an empty
JSON array.
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
nt of Bro
Packages makes sense. I always forget how many little tools are laying
around that various people have written to process logs. Having those
in the central repository would be really nice.
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
__
e
corelight/top-dns package.
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ta stores to store and
retrieve your data.
.Seth
--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
zed message.
> >
> > And I think deserializing into 'any' would be needed because it's
> > not possible to e.g. explicitly enumerate all possible types in a Bro
> > script and have a particular event signature to use for any given
> one.
&
nt of the logger is that it doesn't have any script execution tasks
to take care of and it's solely dedicated to logging. What's the
problem you're trying to solve by running code there?
.Seth
--
Seth Hall * Corelight, Inc * s.
Any opinions?
I'd be fine with that. I think master is quite stable right now anyway.
.Seth
--
Seth Hall * Corelight, Inc * s...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
king of this, I think we still need to have broctl autogenerate a file with
this configured to a random value when it starts up (if that file doesn't
already exist). That way everyones cluster will end up with a random value
that stays consistent across restarts.
.Seth
--
Seth
I'm casting around for thoughts on adding a mechanism to add the
ConfigurePackaging cmake packaging mechanism to plugins without having to
replicate the cmake script in the main cmake repository or making near-clones
of it. Is there some way we could use that script from the main Bro repository
veruse of "when" for instance).
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
many we could avoid
with static linking.
- We would probably have to create more project infrastructure to build
packages.
Other thoughts?
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
ll of a protocol ephemera tied closely with
it.
Would that work? I know that internal and external plugins have some
differences, but I don't know if that means we're limited in a bit in how we
handle script land required data structures for analyzers.
.Seth
--
Seth Hall
Intern
know that in the current programming model, making this cluster aware but
still work not on a cluster can be painful to create the right abstraction.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
__
writes out the data it receives.
Just to pile onto this, I think it should be this way too. I'd really like to
avoid script code executing on the logger.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has
e at all? I think we've had too many new Bro
programmers get frustrated with this behavior which worries me a little bit.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
e thing with the mugs kind of fell flat anyway. :(
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
an really complain here.
>> I find "Error::Success" really unintuitive and kind of funny too. :)
>
> Yeah, agree, that's part of the question what namespace to use.
> "Broker::Success" would certainly be nicer.
Yep.
.Seth
--
Seth Ha
cast the value
to an error type, maybe like this...
if ( v as error == Error::Success )
I find "Error::Success" really unintuitive and kind of funny too. :)
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
aving nicely generalized error handling in Bro would be such
a huge benefit for script authors.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mai
rectives choosing to load certain scripts on
different systems, etc).
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.
-tracker.atlassian.net/browse/BIT-1711?filter=10001
> Seth, this is just waiting on more feedback on the problem I think
Left a note.
I'll be working on stuff this weekend... again. :)
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
h
> On Sep 22, 2016, at 10:45 AM, Seth Hall wrote:
>
> Yeah, I think changing bro-cut is too far gone at this point. I was only
> asking about bro-pkg because it's so new and so few people have it installed.
Quick follow up. I'm fine leaving things as-is. It's c
use it's so new and so few people have it installed.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
cause the conn_id is used at a table
index in a lot of places.
Is there somewhere else you could stash the information that you need?
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
__
What does everyone think about making a change to rename bro-pkg to bropkg? I
think we're early enough that we could probably get away with it and it fits
with more with existing tools like broctl. I find it difficult to type the
hyphen too for some reason.
Thoughts?
.Seth
--
Seth
was reading Michal's email poorly. Everyone seems to be on
the same page.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mailing list
bro-dev@bro.org
http://mailman
e 2.5 release hasn't happened yet. :)
Jan, would you mind if we posted this directly to the Bro blog? (obviously with
all credit given to you!)
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
_
s(const char*, yy_size_t)’:
> /home/jgras/devel/bro/build/src/scan.cc:3286:19: warning: comparison
> between signed and unsigned integer expressions [-Wsign-compare]
> for ( i = 0; i < _yybytes_len; ++i )
>
>
that things are working ok, but I don't have any clue what
would feel right or wrong.
> [ 0%] coverage.bare-mode-errors ... failed
Whoops. Fixed.
Thanks,
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyo
one sees any trouble, let me know.
Thanks,
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
that SMB is now in master. :)
If you want to run it, make sure you load policy/protocols/smb because it isn't
loaded by default.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.br
ame would be
> user/redis, for example, and there also could be user2/redis?
I may have lost track of the design so I don't know where things stand now, but
I think this would make sense too.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has
ining
individual plugins that provide a variety of features.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
t doing the log. There
is one minor issue that this brings up though in that right now certificate
hashes are all given in the files.log. We could move them elsewhere like
x509.log or ssl.log, but I'm curious if anyone had thoughts on what they think
would be most useful?
.Seth
--
Set
ngle noticed to watch for for "scanning". Having to watch for two
different notices always felt a bit unnatural. I think that I personally care
about scans, not the type of scan being performed (although there may be some
nuance to that that someone is taking advantage of?).
.Seth
-
> On Jun 23, 2016, at 2:33 PM, Daniel Thayer wrote:
>
> Could you specify what the problem is with the current implementation in git
> master?
I see it now. I'll close again.
Thanks!
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone h
done when he closed it either so
I thought it might have been a mistake.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.ics
> On Jun 23, 2016, at 12:52 PM, Slagell, Adam J wrote:
>
> https://bro-tracker.atlassian.net/browse/BIT-1551
I reopened this ticket since it looks like it was wrongly closed.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://ww
> On Jun 23, 2016, at 12:52 PM, Slagell, Adam J wrote:
>
> https://bro-tracker.atlassian.net/browse/BIT-1551
Great! Thanks Adam (and Daniel!).
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://ww
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 packet source plugins are showing up in the bro-plugins
repository.
.Seth
--
Seth Hall
International Computer Sc
use suddenly it suddenly feels very natural
to explain the contents of a package (or whatever it ends up getting called).
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-d
> On Jun 9, 2016, at 5:32 PM, Siwek, Jon wrote:
>
> I like the “packages” + “package-manager” combo that Johanna suggests.
I like that too. It feels nice and clean.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://ww
ves on the
NCSA dev cluster yet? I'd be curious to hear if that fixes the problem. Or do
you even see this issue on that cluster?
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
__
ing written that are seconds to minutes old.
This isn't exactly a request for anyone to do anything, but more a call for
anyone that would like to dig around in the core to figure out what is going on
here so we can get a fix merged into master.
Thanks!
.Seth
--
Seth Hall
International C
y sounds
> good to me.
Agreed, looking forward to the changes Jan!
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[
https://bro-tracker.atlassian.net/browse/BIT-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Seth Hall updated BIT-1581:
---
Description:
This branch is ready to be merged. It makes the "misc/stats.bro" much more
[
https://bro-tracker.atlassian.net/browse/BIT-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Seth Hall updated BIT-1581:
---
Status: Merge Request (was: Open)
> topic/seth/stats-improvem
Seth Hall created BIT-1581:
--
Summary: topic/seth/stats-improvement
Key: BIT-1581
URL: https://bro-tracker.atlassian.net/browse/BIT-1581
Project: Bro Issue Tracker
Issue Type: Improvement
> On Apr 20, 2016, at 3:49 PM, Robin Sommer wrote:
>
> No, but I also didn't look further. Could it be the new file
> identifications (i.e., the regexps)?
That was my thought too. I'll have to look into DFA state creations to see if
we've walked into that problem a
d (+9.8%)
Did you ever happen to figure out what was going on with this?
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.ic
> On Apr 13, 2016, at 4:32 PM, Seth Hall wrote:
>
> It was a macro expansion name conflict.
Oops! Now I noticed that you committed into fast path! We did the same fix at
least. I suppose we should revert your change out of fast path now. I'll take
care of that.
.Seth
e conflict.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[
https://bro-tracker.atlassian.net/browse/BIT-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Seth Hall updated BIT-1566:
---
Resolution: Merged (was: Fixed)
Status: Closed (was: Merge Request)
Merged with commit
Seth Hall created BIT-1568:
--
Summary: Add rtt field to dns.log
Key: BIT-1568
URL: https://bro-tracker.atlassian.net/browse/BIT-1568
Project: Bro Issue Tracker
Issue Type: Improvement
[
https://bro-tracker.atlassian.net/browse/BIT-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Seth Hall reassigned BIT-1566:
--
Assignee: Seth Hall
> RFB (VNC) protocol analy
Seth Hall created BIT-1558:
--
Summary: Bro's ascii formatter writing out scientific notation
Key: BIT-1558
URL: https://bro-tracker.atlassian.net/browse/BIT-1558
Project: Bro Issue Tracker
> On Mar 11, 2016, at 5:33 PM, Robin Sommer wrote:
>
> This seems to be causing a number of baseline mismatches in the
> external test suite. I can't tell if they are legitimate, did you run
> the tests?
Fixed.
.Seth
--
Seth Hall
International Computer Science Ins
> On Mar 11, 2016, at 5:33 PM, Robin Sommer wrote:
>
>
> On Fri, Mar 11, 2016 at 12:56 -0500, Seth Hall wrote:
>
>>Files transferred over FTP were showing incorrect sizes.
>
> This seems to be causing a number of baseline mismatches in the
> external test s
Seth Hall created BIT-1544:
--
Summary: File analysis code fails due to CheckString
Key: BIT-1544
URL: https://bro-tracker.atlassian.net/browse/BIT-1544
Project: Bro Issue Tracker
Issue Type: Problem
> On Feb 23, 2016, at 10:07 PM, Matthias Vallentin wrote:
>
> That's currently not supported, but it's on the wish list [1].
Ah, I haven't read through the broker extensions page in much detail yet.
Thanks!
.Seth
--
Seth Hall
International Computer Science Institut
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.
.Seth
--
Seth Hall
International Computer Science Inst
[
https://bro-tracker.atlassian.net/browse/BIT-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24201#comment-24201
]
Seth Hall commented on BIT-1521:
What if you change known_services to...
{code}
table[
s to be done on the manager.
I think that giving up that information is reasonable and we do it.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mailing list
bro-dev@
e messy
cross-structure stuff can happen in scripts.
> Any help on this is much appreciated; especially if you think I am
> overlooking a hidden can of worms somewhere ;-)
>From what you've described here and in our off-list emails, I think you're on
>the right track.
d be good for us if we stopped using it completely.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ake sure that this is included there for any future plugins that are
created.
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mailing list
bro-dev@bro.org
http://mailman
which I don't quite understand as c++11
> should be on by default, no?
Oh, is the elasticsearch plugin being built with C++11 enabled?
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
route as it probably would be to
> slow and then we would have two places where this parsing is done.
This is almost certainly not a great idea as you learned. :)
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyo
[
https://bro-tracker.atlassian.net/browse/BIT-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=23922#comment-23922
]
Seth Hall commented on BIT-1510:
I'm actually not completely sure of all of the ca
1 - 100 of 568 matches
Mail list logo
