[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#981446: offering to help



Hi - longtime logcheck user here (since 2004 at least).

Very keen to keep logcheck in the distribution and looking to get involved in Debian (spare time only).


happy to submit patches etc but how should that be done - to the bts or via salsa? will anyone review and merge things?

Is there an email list to enable collaboration and discussion?


It seems to me that logcheck needs some or all of:

1. refreshed documentation (for example i can see from the source that the systemd journalctl is being consulted as well as syslog but exactly what "logs" now include needs documenting. There also seems to have been some drift between documentation, rules, and the main script.

2. review and potential incorporation of patches and other things in the bts

3. very simple "macros" /tags to make rules easier to write (but this needs to be kept very simple)

4. systend timer as well as cron job

5. (potentially controversial) a simplification of concepts -- i dont find either of the server/workstation/paranoid or the violations/cracking concepts really that helpful and feel it could all be simplified. 
My view is that would be better to have a simpler setup where rules files are either enabled or not and the user would pick and choose what they want. This could take account of which packages are installed so if you dont have apache you dont apply the apache "rules" at all, which might also make things faster.


6. Underlying all this is a need for a clearer statement of what logcheck is for: is it security tool or merely something that filters logs? - in my view, the latter is more important and the benefits to security are more incidental. 

All the above needs to learn from and incorporate what is already there - it's not a huge rewrite at all but evolution.


R


Reply to: