[IntelMQ-dev] config format (Is: IEP01: IntelMQ Configuration Handling)

[Birger Schacht]

Hi everyone,

thanks a lot for the input on the proposal, its really great such 
valuable feedback! And I think its a good sign that at least until now 
the format of the configuration file seems to be the most controversial 
part of the proposal ;)

I must admit I didn't really think about having access to the comments 
in the manager, but its a good point and I can see the value in that. I 
guess that comments being part of the data itself would be a solution 
that works for all the formats we listed, isn't it?
We could simply introduce a "-comment" suffix that would work for every 
key. What I'm not sure about right now is how the respective Python 
libraries handle the ordering of keys. As Bernhard mentioned, the 
comment should be nearby the value it refers to. I guess the most common 
ordering would be alphabetical, so if we add a "-comment" suffix the 
comment would be listed below the value. We just have to make sure 
comment and value are kept together when the file is updated 
programmatically.

One other thing that might be relevant: I think the manager should not 
have to deal with the file-format IntelMQ uses internally. I think the 
communication between API and intelmq-manager should still use JSON, and 
the conversion should be done by the API, but I don't think that would 
be a problem.

cheers,
Birger

On 12/18/20 6:45 PM, Bernhard Reiter wrote:
> Hi Filip,
> 
> thanks for the discussion, I'll answer you and Aaron in one go:
> 
> Am Dienstag 15 Dezember 2020 19:43:25 schrieb Filip Pokorny:
>> It doesn't improve GUI approach via Manager, but it doesn't break it or
>> remove functionality either.
> 
> I think it would in a subtle way.
> (My aim is to point that way out first, not to recommend a decision in one or
> the other way.)
> 
> Usually an out-of-band comment has interesting info
> (otherwise it would be senseless)
> and the info is related to the values nearby.
> 
> So if the gui (editor) changes the value and cannot see the out-of-band
> comment, but preserves it, the comment will not match the value anymore
> and that the comment will be potentially broken. So one system will
> be the leading system unless all comments are in-band.
> 
> 
> Am Dienstag 15 Dezember 2020 17:25:21 schrieb L. Aaron Kaplan:
>> But in the past, the very long JSON (no comments) format has been,
>> well..  a bit cumbersome.
> 
> Optional in-band comments could be introduced.
> The default formatting could be made human readable and compact.
> 
> Otherwise the length maybe a problem of putting to much into one file?
> 
>> How do other projects do their config language
>> for large and complex configs?
> 
> I guess there is no silver bullet, each product will look at its requirements
> and use cases. Some put "config" data not into a "language", but consider it
> internal state that is managed by frontends.
> 
> Best Regards,
> Bernhard
> 
> 
> _______________________________________________
> IntelMQ-dev mailing list
> IntelMQ-dev at lists.cert.at
> https://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev
> 

-- 
// Birger Schacht <schacht at cert.at>
// CERT Austria - https://www.cert.at/
// Eine Initiative der nic.at GmbH - https://www.nic.at/
// Firmenbuchnummer 172568b, LG Salzburg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x3A3C547D2D48D997.asc
Type: application/pgp-keys
Size: 5392 bytes
Desc: not available
URL: <http://lists.cert.at/pipermail/intelmq-dev/attachments/20201222/0a83bb9c/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/intelmq-dev/attachments/20201222/0a83bb9c/attachment.sig>