[RFC] Future audit changes

Hello, I am considering making some drastic changes in a future 4.0 release. This is partly motivated by a change in my daytime job. I am no longer working in Red Hat security. Therefore working on audit is officially a hobby. I have spent the last weeks closing out pull requests and Issues so that whoever wants to contribute to the audit project doesn't have a lot of history to deal with. There's almost 500 people subscribed to this list. The community needs to step up a little. The proposed changes are: 1) Drop support for Python 2. Python 2 has lost upstream support over 3 years ago. I also can't see the viability of someone saying they need the latest audit changes for the new kernel yet they are stuck on python 2. It doesn't compute. This is also related to proposal 5 below. 2) Drop SysVinit support. I think everyone has changed to systemd at this point. This is to reduce potential maintenance. 3) This is probably the most controversial and would need careful testing: Split the audit service into 2 services: auditd and rules-load. These would be packaged in 2 different packages so that if all you want is rules-loading and are fine with events going to journald - have at it. If you want the tradition audit experience, then install the audit package which will depend on the rules package. The trick is making them automatically enabled at install. This will need testing and perhaps patches. Packagers will need to work with their distribution to update systemd presets. 4) Change the definition of which events are simple (one record events) and compound (multiple records per event). Over the years syscall records were added to the simple events haphazardly. That seems to have settled down and we can redefine which are in which group. This is important because this determines when an event is complete and ready to process in ausearch, aureport, and auparse. This should reduce future bug reports. 5) Drop functions from libaudit python bindings that have anything to do with placing and removing rules in the kernel. I'd like the API to just contain what's needed to send audit events and query kernel status. This new binding would be hand written, thus possibly breaking compatibility with the swig generated bindinsg. Not 100% sure on that, but it might be a side effect. The main idea is limit the scope to reduce maintenance and future-proof kernel/ swig changes. 6) Moratorium on new arches being supported. If someone else comes along and really shows *sustained* support for the audit project for a while and they want a new arch to be supported, I might consider it. Since my work on this project is now a hobby, I am not inclined to make more work for my weekends. 7) Drop the autrace & auvirt programs. Does anyone actually use these? Can ausearch take the place of auvirt? The aim here is reduce maintenance. Let me know what you think. I'll probably put these in a new audit-4.0 branch until they are complete and some testing has been done. -Steve