Daniel, rathter than simply removing the piece of code, can we put in
a 2.2 version instead to achieve the same effect?
Robin
I think it's a bad idea to have script code in local.bro (besides
"@load") because it will not be updated when a user upgrades to a
newer release of Bro. Also, the fact that it's commented-out by
default means it's not going to be tested, and most likely nobody
will notice (for a while) when something else changes that breaks
that code.
Perhaps instead we could put something in scripts/policy/misc/ (or
somewhere else?), and then @load that from local.bro (the @load
would be commented-out by default).
Even though the example would be commented out, that's defying the “best practice” of the only code in local.bro being @loads — it generally simplifies the upgrade procedure both for a user that wants to use the new upstream version and for a dev/maintainer that wants to set new defaults for things.
Maybe putting the example closer to the Notice::policy documentation (either within the Broxygen comments or the general Notice Framework docs) is better. There, it’s easier to regression test, more likely to be changed if a dev makes incompatible changes to notice scripts, and more accessible to users.
- Jon
Ok, makes sense to leave it out of local.bro. Whether to put it
elsewhere depends on how many people might actually use it I guess.
I'll merge as is for now.
Robin