10 Feb
2017
10 Feb
'17
9:51 a.m.
What do people think about splitting up portions of init-bare into separate
files, and having init-bare simply @load those files? Right now, it's a
4500+ line script that keeps growing, and it commonly results in conflicts.
For the protocols, I could see having a file such as
protocols/kerberos/bare.bro which defines the appropriate types which are
currently in init-bare.
--Vlad
10 Feb
10 Feb
10:03 a.m.
On Fri, Feb 10, 2017 at 11:51:08AM -0600, Vlad Grigorescu wrote:
What do people think about splitting up portions of
init-bare into separate
files, and having init-bare simply @load those files? Right now, it's a
4500+ line script that keeps growing, and it commonly results in conflicts.
For the protocols, I could see having a file such as
protocols/kerberos/bare.bro which defines the appropriate types which are
currently in init-bare.
That sounds like a good idea - I am not a big fan of the fact that a lot
of the protocol dependent datatypes are in init-bare currently.
I am just not sure if it might require a lot of fiddling to get the load
order of things correct; but assuming that every protocol has a bare.bro
(or perhaps a datatypes.bro or similar?), that should not be a huge issue.
Johanna
11 Feb
11 Feb
9:20 p.m.
On Feb 10, 2017, at 1:03 PM, Johanna Amann
<johanna(a)icir.org> wrote:
If we started structuring the analyzers internally more like external plugins with the
scripts and everything in them, it would feel more comfortable to me. It seems like
we'd be able to keep all 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
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
For the protocols, I could see having a file such
as
protocols/kerberos/bare.bro which defines the appropriate types which are
currently in init-bare.
That sounds like a good idea - I am not a big fan of the fact that a lot
of the protocol dependent datatypes are in init-bare currently. 
12 Feb
12 Feb
11:25 a.m.
On Sun, Feb 12, 2017 at 00:20 -0500, you wrote:
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.
For init-bare-style initialization code I was thinking the same, and
that's also partially where my __bare__.bro idea came from (actually
__init__.bro would be nicer I'm thinking now). I went back to the
plugin structure to see if we have the right mechanism there already,
but they work slightly different in terms of when required data
structures get initialized. But we could make those __init__.bro
scripts work in either case I think.
For a more general reorganization of moving scripts and code together,
I'm still torn on that. I like that in theory, but haven't convinced
myself yet that I'd like it in practice. :)
Robin
--
Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin
10 Feb
10 Feb
7:13 p.m.
On Fri, Feb 10, 2017 at 11:51 -0600, you wrote:
What do people think about splitting up portions of
init-bare into separate
files
Yeah, I can see that. It would be nice, though, if init-bare.bro
wouldn't need lots of @load statements then to refer to the individual
files. Maybe we could add some automatic way instead, like calling the
files __bare__.bro and have Bro find them automatically (but to
Johanna's point, not sure if that would cause load-order problems).
Robin
--
Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin
1525
days inactive
1527
days old
4 comments
4 participants
participants (4)
-
Johanna Amann -
Robin Sommer -
Seth Hall -
Vlad Grigorescu