[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