[IntelMQ-dev] RFC on IEP007: Running IntelMQ as Python Library

[Sebix]

Dear Mika, dear Aaron,

On 4/25/23 1:43 PM, Mika Silander wrote:
>  References to the discussions on motivations for the library proposal
> are welcome, but when and if you find them, IMHO I think the best
> location for them is the IEP itself. The document could for example,
> start with a "Background" or similar section that tries to answer why
> this is a desired thing, what benefits it would bring and maybe some
> examples.

I have added a new section with another example and a proposal how it
can/will be used in the IntelMQ Webinput:

https://github.com/certtools/ieps/tree/iep-007/007#user-content-use-cases

The code examples are not yet consistent, as they are to be discussed
and I work on proof of concepts (i.e. researching what interface options
are possible/doable) in parallel.

> A long time ago I wrote a wrapper script that allowed chaining bots on
> the command line. It did of course not provide all the features that
> are outlined in your IEP, but it gave me the possibility to simple
> sampling of events and testing bots with e.g.
>
> wrapper BotA | wrapper BotB | wrapper BotC ...
Oooh, that's interesting as well! Although not the same as this
proposal, it somehow goes in a similar direction
>  What comes to the API-breaking vs. less intrusive implementation, I
> think I did understand these were two separate options, but the
> API-breaking I found a bit scary and reacted to that only. And yes, I
> can imagine it's been a big effort to reach versions 3.0 and 3.1. Had
> I known all the effort I've had to do put to the interconnected
> systems related to our IntelMQ setup (IntelMQ itself was not that
> hard), I would have never even started :-).
Hehe, oh yeah, I feel your pain. Getting systems interconnecting
together, month-long fiddling around in various scripts, and setting up
proper management, monitoring, other supporting systems around all that,
docs - lots of work.
> Still, as said, my vote is on the less intrusive implementation option
> and sticking to KISS, but if it turns out the API-breaking one wins,
> please consider techniques that could provide some degree of backward
> compatibility as I suggested.
ACK
>  I don't think I'm a very active debater on this forum, so it would be
> nice to read what other developers think. Especially the ones like me
> who do not form part of the core developers but just need to add some
> components and features of their own to IntelMQ.

+1

On 4/25/23 1:52 PM, L. Aaron Kaplan wrote:
> I think maybe it also helps to clearly explain what Sebix meant by "API breaking change"?
The word "API" has two meanings here
1. The program "IntelMQ API", the managers interface
2. The application program interface of IntelMQ (Core) itself, i.e. the
methods, its parameters etc.
> I.e. internally the API for the Bot class changes (and can be search&replaced & refactored for all code and all the developers get informed) Or... this also breaks the (hug/fastapi) API ? ;-)

In this case I meant the program interface of IntelMQ and more
specifically I addressed the function signature of Bot.process. A change
here would mean the process() methods need to be adapted, or a
compatibility layer introduced (is possible with Python's built-in code
inspection).

So far, we all agree that we do not want to make this step (now).

best regards
Sebastian

Institute for Common Good Technology
gemeinnütziger Kulturverein - nonprofit cultural society
https://sebix.at/
ZVR 1510673578

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/intelmq-dev/attachments/20230426/18b6d915/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/intelmq-dev/attachments/20230426/18b6d915/attachment.sig>