[IntelMQ-dev] Potential attribute name clashes in bot parameters in intelmq 3.1.x ?

[Mika Silander]

Hi Sebastian, all,

 Thanks for the clarification. Yes, I was admittedly surprised by this turn in development. It simplifies things yes, but especially to newcomers this might provide a confusing surprise. Pondering on solutions to this I thought one could isolate these intelmq infra-reserved configuration parameters and bot specific parameters into two separate sets so as to maintain name space hygiene. It means of course we'd also need to modify the structure and parsing of runtime.yaml to accomodate these two sets and maybe implement slightly old-fashioned getters and setters for manipulating these parameters but the end result would imho be clearer and no risk for clashes at a small additional cost of coding.

Br, Mika

----- Original Message -----
From: "Sebastian Wagner" <wagner at cert.at>
To: "Mika Silander" <mika.silander at csc.fi>, "intelmq-dev" <intelmq-dev at lists.cert.at>
Sent: Tuesday, 2 November, 2021 15:11:36
Subject: Re: [IntelMQ-dev] Potential attribute name clashes in bot parameters in intelmq 3.1.x ?

Hi,

On 10/8/21 1:17 PM, Mika Silander wrote:
>  At long last I updated my develop branch from the 2.3. days to 3.1.0 and noticed my tests fail due to the fact that bots don't have anymore a "parameters" attribute. At a closer look it seems all parameters from runtime.yaml are turned into direct attributes of self (correct?), e.g. if one defines a conf parameter "myparam", this shows up in the bot as self.myparam and not accessible as getattr(self.parameters, "myparam") as it did before.
>
>  After experimenting with my own bot tests I ended up in a situation where there's a potential attribute name clash. Assume a bot is tested like
>
> self.input_message = some_event_here
> self.run_bot()
> self.assertSomethingHere()
>
>  In the above test, the bot gets initiated with a big number of default attributes, e.g. accuracy, group, enabled, logger, run_mode etc etc. Assume then that as a developer I want to use parameters with matching names for the needs of my own bot like
>
> self.input_message = some_event_here
> self.run_bot(parameters={
>     'group': 'Plumber',
>     'run_mode': 'disruptive'
> })
> self.assertSomethingHere()
>
>  I can set those parameters and they happily override the defaults and I imagine this can mean trouble ahead. Is this intended behaviour and if yes, is there a way to prevent it? With the earlier self.parameters construct this did not happen and one could have e.g. a "group" attribute for the needs of intelmq's internal operation (self.group) separate from a bot developer's "group" attribute (that ended up under self.parameters) - no clashes despite equal names.
>
>  Thus, to avoid the above in intelmq 3.0.x this means every bot developer needs to check her own bot won't use any of the 'reserved' attributes before defining their own ones, right?

"group" is one of the values which is reserved/used my the Bot class
itself:
https://github.com/certtools/intelmq/blob/7ebb8e16d821c372a44b077dd18a151c07f75807/intelmq/lib/bot.py#L62

Sorry for causing the confusion. We can only take care of the bots that
are part of IntelMQ itself and make sure they are compatible, not for
the bots unknown to us. Still, I hope that the simplifications and
advantages of the new approach outweigh your disappointment.

Sebastian

-- 
// Sebastian Wagner <wagner at cert.at> - T: +43 676 898 298 7201
// CERT Austria - https://www.cert.at/
// Eine Initiative der nic.at GmbH - https://www.nic.at/
// Firmenbuchnummer 172568b, LG Salzburg