[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