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
- berk
- bob
- bip
Looking forward to hear your ideas.
Matthias
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<blocking>();
e.subscribe("/foo");
e.subscribe("/foo/bar");
e.subscribe("/foo/bar/baz");
e.publish("/foo/bar/baz", 4.2);
Should the endpoint receive exactly one message or the same message
three times? Personally, I think use exactly-once delivery semantics
would be most intuitive.
Matthias
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 Science Institute
(Bro) because everyone has a network
http://www.bro.org/
Hi,
I have a few things I am planning to add to the intel-framework. One of
them is expiration for intelligence items. To achieve per item
expiration in a table there is a little hack that is used in the
notice-framework and in the new netcontrol-framework: By setting
&create_expire=0 and returning the intended timeout for each item in the
corresponding expire_func, one can achieve per item expiration (see e.g.
scripts/base/frameworks/netcontrol/catch-and-release.bro).
This approach however does not work for &read_expire and &write_expire,
because accessing the item resets the expiration timeout based on the
&read/write_expire attribute of the table (in this case 0) instead of
the value that was previously returned by the expire_func. The following
script demonstrates this effect:
https://gist.github.com/J-Gras/061983dac59224a03d3bfad4476a1dd9
The straight-forward solution would be to allow each item to hold its
own expiration timeout. Talking to Seth about this, we came up with two
possible approaches to achieve this:
1) Use the return value of the expire_func to set this value.
2) Use a bif or language feature (e.g. expire 10sec { tbl[idx] }; ) to
set this value.
I would prefer the second approach, as the intention of the expire_func
return value is to provide a delay for a single expiration event. This
would e.g. allow to set an individual expire timeout of e.g. 1 hour for
a single item. Once the expire_func is called one could set a delay of
e.g. 10min. In case the item is accessed, the timeout would be reset to
the originally intended 1 hour instead of 10min.
What are your opinions on that? Which approach would you prefer or do
you think per item expiration is a bad idea in general?
Best regards,
Jan
http://arstechnica.com/security/2016/06/college-student-schools-govs-and-mi…
------
Adam J. Slagell
Chief Information Security Officer
Director, Cybersecurity Division
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
www.slagell.info
"Under the Illinois Freedom of Information Act (FOIA), any written communication to or from University employees regarding University business is a public record and may be subject to public disclosure."
I just stumbled across this in src/bif_type.def. My understanding of the
internal BRO type system is a bit fuzzy so I'm not 100% sure this is wrong
-- and I can't point to anything that doesn't work -- but it sure doesn't
*look* right.
// DEFINE_BIF_TYPE(id, bif_type, bro_type, c_type, accessor, constructor)
...
DEFINE_BIF_TYPE(TYPE_INT, "int", "int", "bro_int_t",
"%s->AsInt()", "new Val(%s, TYPE_BOOL)")
Is there some reason why "new Val(%s, TYPE_BOOL)" is correct for the
TYPE_INT constructor here?
(This is in master branch but has been like this since the beginning of the
git repo.)
Thanks,
Jeff
