On Sun, 19 Jul 2020, Kevin A. McGrail 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??
One detail that I'm not in a good position to estimate is the impact of
this on the rules compiler.
The "alias" directive should not affect RE rules at all, other than
perhaps removing one if the alias is defined after a RE rule having the
same name was defined. The big effect of "alias" on rules is on metas,
where it would substitute the root rule name in place of the alias name in
any meta expression where it appeared (this to avoid having the meta rule
logic being modified to be aware of aliases).
I'm assuming that the rules compiler is given the parsed RE rules
collection after the config parsing is complete, and I don't expect the
rules compiler does anything with meta rules, so I *think* that adding an
"alias" directive would not affect the rules compiler at all.
Can someone more familiar with the rules compiler confirm whether my
impression is correct?
>> 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?
As discussed, the "report" option seems needed, or defining "meta XXX"
would remove "alias XXX". I'm still thinking about this one.
I suspect having "meta XXX" remove "alias XXX" will open the risk of
unexpected behaviors especially with respect to scoring, so I'm leaning
towards a "report" option on the alias directive and having "meta XXX"
emit a lint error if "alias XXX" already exists as being more reliable in
use.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Venezuela is busy reaping the benefits of Socialism:
in one year 75% of the population has, on average, lost 19 pounds
due to insufficient food, and 82% of households are below the
poverty line. (2016 Venezuelan "Living Conditions Survey")
-----------------------------------------------------------------------
103 days until the Presidential Election
>> 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??
One detail that I'm not in a good position to estimate is the impact of
this on the rules compiler.
The "alias" directive should not affect RE rules at all, other than
perhaps removing one if the alias is defined after a RE rule having the
same name was defined. The big effect of "alias" on rules is on metas,
where it would substitute the root rule name in place of the alias name in
any meta expression where it appeared (this to avoid having the meta rule
logic being modified to be aware of aliases).
I'm assuming that the rules compiler is given the parsed RE rules
collection after the config parsing is complete, and I don't expect the
rules compiler does anything with meta rules, so I *think* that adding an
"alias" directive would not affect the rules compiler at all.
Can someone more familiar with the rules compiler confirm whether my
impression is correct?
>> 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?
As discussed, the "report" option seems needed, or defining "meta XXX"
would remove "alias XXX". I'm still thinking about this one.
I suspect having "meta XXX" remove "alias XXX" will open the risk of
unexpected behaviors especially with respect to scoring, so I'm leaning
towards a "report" option on the alias directive and having "meta XXX"
emit a lint error if "alias XXX" already exists as being more reliable in
use.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Venezuela is busy reaping the benefits of Socialism:
in one year 75% of the population has, on average, lost 19 pounds
due to insufficient food, and 82% of households are below the
poverty line. (2016 Venezuelan "Living Conditions Survey")
-----------------------------------------------------------------------
103 days until the Presidential Election