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

[Mika Silander]

Hi,

 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?

 I might and I definitively hope I'm wrong here but please let me know if this is the case.

Br, Mika