eval?

[Seth_Hall3]

I imagine that an eval BiF would be pretty easy to write and it would make it possible for me to do what I'm working on now. I'll write a bit about what I'm working on to justify an eval BiF.

I'm reworking most of the notice framework to make it simpler and make it's features more well defined, mostly by removed the notice action filters. The notice action filters are confusing because they are applied after the notice policy but that's effectively creating two different ways for actions to be applied to notices but it just makes things confusing in the end. I think the notice action filters were originally created as a shorthand way to provide broad brush strokes to the notice policy by directing entire notice types toward certain actions.

If we had an eval function, I could essentially replicate this functionality in the notice policy which would keep everything much clearer. As things stand now (before I do a commit), here's how it looks to filter out entire notice types:

redef Notice::action_filters += {
        [[DPD::ProtocolViolation]] = Notice::ignore_action,
};

I would like to do something like this...

redef Notice::policy += {
  Notice::ignore_it(DPD::ProtocolViolation),
};

The problem is that to implement the ignore_it function requires me to dynamically implement the predicate for the notice policy which Bro doesn't currently like. I tried implementing it similarly to this:

function ignore_it(nt: Notice::Type): Notice::PolicyItem
  {
  return [$result=ACTION_IGNORE,
          $pred(n: Notice::Info) = { return n$note == nt; },
          $priority=5];
  }

I think the problem comes up when Bro is interpreting "n$note == nt". It isn't pulling the values from the correct namespace. If I could call an eval function, I could implement it this way:

function ignore_it(nt: Notice::Type): Notice::PolicyItem
  {
  eval(cat("return [$result=ACTION_IGNORE, $pred(n: Notice::Info) = { return n$note == ",
    nt,
    "; }, $priority=5]");
  }

I think it would be fairly reasonable for eval to only work at init time too. It scares me to think of eval being usable at runtime. Sorry for the long email, but any thoughts?

  .Seth

[Vern]

Yuck.

This strikes me as definitely going down the wrong path - making code less
clear rather than more clear.

redef Notice::action_filters += {
        [[DPD::ProtocolViolation]] = Notice::ignore_action,
};

I would like to do something like this...

redef Notice::policy += {
  Notice::ignore_it(DPD::ProtocolViolation),
};

I'm not understanding how the second is better than the first. Indeed,
now I have to go look at how ignore_it works to know what's going on.

The problem is that to implement the ignore_it function requires me to dynamically implement the predicate for the notice policy which Bro doesn't currently like. I tried implementing it similarly to this:

function ignore_it(nt: Notice::Type): Notice::PolicyItem
  {
  return [$result=ACTION_IGNORE,
          $pred(n: Notice::Info) = { return n$note == nt; },
          $priority=5];
  }

Here it seems if you must go this route, the right fix is either a notion
of currying (or partial application) of functions, or to have a single
PolicyItem for ignoring that looks up n$note in a table, and just add
DPD::ProtocolViolation to that table.

    Vern

[Seth_Hall3]

This strikes me as definitely going down the wrong path - making code less
clear rather than more clear.

Heh, exactly why I was looking for feedback.

I'm not understanding how the second is better than the first. Indeed,
now I have to go look at how ignore_it works to know what's going on.

Syntactically it wasn't really any better. I guess I wasn't very clear in my email earlier. What it was doing was clearing up a somewhat ambiguously defined area internally in the notice code by getting rid of the action_filters since the notice policy does essentially the same thing but in a different way. Having both methods can bite you because you have to know the internal organization of the notice framework to effectively use it.

Here it seems if you must go this route, the right fix is either a notion
of currying (or partial application) of functions, or to have a single
PolicyItem for ignoring that looks up n$note in a table, and just add
DPD::ProtocolViolation to that table.

That's exactly what I ended up doing right after I sent the email.

I'm almost certain I've still missed some use case for the notice framework or made some odd design decisions (I think I'm well known for those!), but I'll fix everything once the script gets reviewed more closely.

Thanks for trudging through that whole email.

  .Seth

[robin]

For the record, I don't think this would be easy at all.

Robin

[Seth_Hall3]

Hah, ok.

  .Seth