On Tue, Oct 16, 2018 at 2:23 PM Vlad Grigorescu <[email protected]> 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 _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
