aaronkaplan
commented
4 years ago Okay, I'll include this thought into the IntelMQ 3.0 planning.
Thanks
On 04.05.2020, at 17:25, otmarlendl notifications@github.com wrote:
There will be updates to the data format and/or data taxonomy that IntelMQ is using. This includes minor updates to the DHO/RSIT in upcoming 2.x versions as well as major changes that 3.0 might make to make streamline things and improve the compatibility with n6 (e.g. multivalue fields).
As a preparatory step I propose that each json object that is passed between the bots should include a field that states which data schema version this object is conforming to.
On the other side, Bots should declare their compatibility with format-versions. The generic Bot class can then raise appropriate errors if a message with an incompatible version is received, or can call appropriate conversion functions.
Right now, this is not strictly necessary, such a framework might come in handy to simplify updates to the data definition and thus make the IntelMQ change management more agile.
Additionally, once we start to interconnect IntelMQ installations of different CERTs, we cannot assume that all installations will use the same software (and thus DHO) version.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
ghost
There will be updates to the data format and/or data taxonomy that IntelMQ is using. This includes minor updates to the DHO/RSIT in upcoming 2.x versions as well as major changes that 3.0 might make to make streamline things and improve the compatibility with n6 (e.g. multivalue fields).
As a preparatory step I propose that each json object that is passed between the bots should include a field that states which data schema version this object is conforming to.
On the other side, Bots should declare their compatibility with format-versions. The generic Bot class can then raise appropriate errors if a message with an incompatible version is received, or can call appropriate conversion functions.
Right now, this is not strictly necessary, such a framework might come in handy to simplify updates to the data definition and thus make the IntelMQ change management more agile.
Additionally, once we start to interconnect IntelMQ installations of different CERTs, we cannot assume that all installations will use the same software (and thus DHO) version.