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

[Sebastian Waldbauer]

Hey again,

The first answer was meant for "Help for fixing configuration of 
intelmq-manager 3.0.1-1", misclicked..


On 10/20/21 12:16 PM, Sebastian Waldbauer via IntelMQ-dev wrote:
> Hey Mika,
>
> Sorry for my late answer. Is the apache 2 correctly configured? 
> Because IntelMQ tries to access the api endpoints, which doesnt 
> respond with any data as it seems.
>
> Have you checked 
> https://intelmq.readthedocs.io/en/latest/user/intelmq-api.html already?
>
> In addition please check the apache configuration file, if its 
> configured correctly :)
>
>
> Cheers,
>
> Sebastian
>
> On 10/8/21 1:17 PM, Mika Silander wrote:
>> 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.

Yes, parameters are now attributes in the bots itself, which was a 
change as part of the IEP01 
(https://lists.cert.at/pipermail/intelmq-users/2020-December/000185.html) 
proposed by Birger Schacht.


>>
>>   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?

Well, everything important should be changed in the lib/bot.py with 
double underscores. Everything else is changable in the bot itself + 
your own attributes.

>>
>>   I might and I definitively hope I'm wrong here but please let me 
>> know if this is the case.
>>
>> Br, Mika
>>
>> _______________________________________________
>> IntelMQ-dev mailing list
>> https://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev
>> https://intelmq.readthedocs.io/
>
-- 
// Sebastian Waldbauer <waldbauer at cert.at> - T: +43 1 5056416 7202
// CERT.at GmbH - https://www.cert.at/
// Firmenbuchnummer 561772k, LG Wien

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1917C49891C4BF92.asc
Type: application/pgp-keys
Size: 3909 bytes
Desc: OpenPGP public key
URL: <http://lists.cert.at/pipermail/intelmq-dev/attachments/20211020/0dfe80ef/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/intelmq-dev/attachments/20211020/0dfe80ef/attachment.sig>