[Bro-Dev] bro-pkg Bro version requirements

[Jon Siwek]

On Tue, Oct 16, 2018 at 2:23 PM Vlad Grigorescu <vlad at es.net> wrote:

>> @if ( Version::at_least("2.6") )
>> event ssl_client_hello(c: connection, version: count, record_version:count, possible_ts: time, client_random: string, session_id: string, ciphers: index_vec, comp_methods: vector of count) &priority=1
>> @else
>> event ssl_client_hello(c: connection, version: count, possible_ts: time, client_random: string, session_id: string, ciphers: index_vec) &priority=1
>> @endif
>
>
> That works, but I worry that the overhead of trying to maintain that will grow out of hand.

I don't have the same worry at least at the moment.  The maintenance
overhead doesn't seem that great: those are fairly trivial lines of
code to understand.  The growth potential also seems low considering
we really don't have cycles to maintain past the last version of Bro
ourselves, so I wouldn't expect packagers to maintain their code to
work against all possible versions.  e.g. in the already-unlikely
chance the same event introduces a breaking change in 2.7, the branch
complexity would not grow if they just throw out the 2.5 branch.

> I'm wondering if there's a better mechanism for this. A naive approach might be to include an option in the package metadata, which specifies minimum/maximum Bro versions that it requires. The installer, then, would simply install the latest version that supports your Bro version.

Interesting thought, but my hunch is it just makes the complexity
implicit instead of explicit.  e.g. if metadata claims it works for
2.6, it's tricky the answer why that is, but with the code above you
can easily search for those specific areas that are version-sensitive.

I'm thinking it may be best to wait and see if there is actually a
problem (lots of people complaining) before trying to decide how to
solve anything.

- Jon