On Sun, 19 Jul 2020, Kevin A. McGrail wrote:
On 7/19/2020 9:29 PM, John Hardin wrote:
I was mulling the utility of a new config directive in 4.0 to address
backwards compatibility of rule names:
alias RULENAME RULENAME_2
...which would recognize any config-file directives for RULENAME and
apply them as if they'd been written for RULENAME_2.
This would discard any existing definition of RULENAME_2 (e.g. header
RULENAME_2 ...), and a definition of RULENAME_2 subsequent to that
alias would be ignored and a lint warning emitted.
That would work well, yes. How big a lift for that alias idea do you
think?
Unknown at this time. I don't *think* it would be too complicated. It
shouldn't affect the bulk of SA, just the config file parsing.
There is the use case of post-SA message processing looking for
specific rule name hits - I can see custom post-SA message processing
looking for a hit on "USER_IN_WHITELIST_TO" et al. To avoid breaking
that we could add a "report" option to the alias command:
alias RULENAME RULENAME_2 report
this seems over complicated. Do you know of anyone doing this use case
that wouldn't just add a meta rule and be done?
Problem is, that's a rule definition and it wouldn't peacefully coexist
with the "alias" directive as I have it envisioned. Perhaps we allow "meta
RULENAME" to remove "alias RULENAME" while retaining the lint warning for
other rule types.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
[email protected] FALaholic #11174 pgpk -a [email protected]
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Back in 1969 the technology to fake a Moon landing didn't exist,
but the technology to actually land there did.
Today, it is the opposite. -- unknown
-----------------------------------------------------------------------
Tomorrow: the 51st anniversary of Apollo 11 landing on the Moon
