[Bro-Commits] [git/bro] topic/policy-scripts-new: Extract packet data for the dpd.log (7c168e0)

Development
1

This is a nice idea but get_current_packet() has some fuzzy semantics:
the current packet is not necessarily the one triggering the event. It
probably works often, but not always, and I'm wondering if when it
doesn't, it could be very confusing to show the data here?

Robin

2

The fairly limited testing I did last night was giving me the correct data. What would you think if I just leave that field disabled by default? We could implement that field in a separate script and put a big disclaimer in the script that about how it could give incorrect packet data. Assuming that people are reading the docs we should be safe.

  .Seth

3

  We could implement that field in a separate script and put a big
  disclaimer in the script that about how it could give incorrect
  packet data.

Yes, I like that.

Assuming that people are reading the docs we should be safe.

We are going from one extreme to the other: from having no docs at all
to making them mandatory to read. :slight_smile:

Robin

4

I replied a bit too fast: an option inside the same script should
already do it; off by default and with a suitable comment. I think we
shouldn't add too many tiny scripts that do things that a boolean
option can achieve just as well. In other words: @load shouldn't
replace redef. :slight_smile:

Robin

5

Haha. Telling me not to replace redef with @load as soon as we have it available as a viable option! :stuck_out_tongue:

I initially thought of an option, but then decided it might be better as a separate script since the field would still be included if I left it as an option and I didn't want the field to show up at all. What do you think? I suppose it doesn't matter if the field shows up and is empty all of the time.

  .Seth

6

Ok, I see that argument. That may actually also be a good rule of
thumb for @load vs redef-an-option: if not setting the option would
still be visible to the user in some non-pleasant form, a script may
indeed be the better way (you may have such rules in your head already
anyway; but I'm still learning them in the new model :-).

Robin

7

I'm going to start documenting all of these rules I have in my head soon. :stuck_out_tongue:

  .Seth