[Bro-Dev] Cmake for Bro
Vern Paxson
vern at icir.org
Mon Oct 18 10:31:15 PDT 2010
> I think the main reason for supporting both was that some systems
> used to come with the former, and others with the latter.
That's my memory too.
> I'm not
> sure how that's today, but I'd be fine supporting just bison. Vern,
> what do you think?
Let's give that a try.
In general, I agree with your config suggestions. Some comments:
> --enable-activemapping enable active mapping processing
> -> Do we want to keep active mapping in the code? Is anybody
> using that?
I don't believe anyone uses this, so it makes sense to remove it.
(Seth: this is an alternative to in-line normalization for resisting
evasion attacks. It works by building up a map of how different end
systems resolve ambiguities. You can read more about it if you want at
http://www.icir.org/vern/papers/activemap-oak03.pdf .)
> --enable-expire-dfa-states enable DFA state expiration
> -> Do we want to keep this in code? Nobody is probably using
> it, and it complicates the DFA code quite a bit.
Seems okay to remove it.
> --disable-nbdns Disable non-blocking DNS support
> -> Remove; don't think anybody uses this.
We can get the equivalent via setenv BRO_DNS_FAKE, right? (Seth: this is
to *avoid* using non-blocking DNS because it won't locally build.)
> --with-openssl=PATH path to OpenSSL (needed for SSL analyzer and secure communication)
> -> Keep, but I'm wondering whether we should make OpenSSL a
> mandatory dependency to get rid of all the "#if openssl"
> conditions.
I like that notion. I guess we'll see whether it leads to portability
problems, similar to bison.
> --with-dag=PATH path to the DAG library (for native support for Endace Tech.'s DAG monitoring cards)
> -> Remove; nobody has been using the native DAG support in
> ages.
Are we pretty sure about that?
Vern
More information about the bro-dev
mailing list