[Bro-Dev] changing Notice::policy mechanism

Siwek, Jonathan Luke jsiwek at illinois.edu
Thu Nov 1 14:47:39 PDT 2012

> - The PolicyItem model (bottom one) has the ability to halt further processing with the $halt attribute of PolicyItems.  I don't think I'm convinced that this is a huge issue.

I think the same thing could be done with the event-model -- if Notice::Info just had a boolean field that each event handler body could check and then bail out early if necessary.  And that field could even be something left up to a user to define in a redef.

> - The evented model has latency from the event queue, but I don't think this is a huge issue.  The latency is normally ok.  Jon, is it an issue for the file analysis framework?

I think the latency is a problem in that case since immediate feedback is helpful if certain actions are to work without buffering incoming file data.  E.g. if the only thing I want to happen is for files to be extracted to disk, then I wouldn't expect that to require buffering.

It may be workable, but I think the latency does make things more complicated so it might not make sense to re-use this policy model for the file analysis framework, but that shouldn't be a showstopper for using it for notices.  I think it's fine to have the policy models be inconsistent, as long as both are easy to understand and use for their purpose.


More information about the bro-dev mailing list