Re: Near Term Audit Road Map

Hi, With the proposals sent to the list, I wanted to talk about how this might play out code-wise. With regard to the current code base, I am working on a 1.8 release. This would represent finishing the remote logging app and nothing more. The 1.8 series would become just an update series just like the 1.0.x series did. In parallel with finishing remote logging, I would release a 2.0 version. Patches applied to 1.8 would also be applied to 2.0. A 2.1 release would signify the completion of remote logging that branch. I would recommend this branch for all distributions pulling new code in. The 2.0 branch will also have a couple more changes. I want to split up the audit source code a little bit. I want to drop the system-config-audit code and let it become standalone package updated and distributed separately. I also want to drop all audispd-plugins in the 2.0 branch and have them released separately. They cause unnecessary build dependencies for the audit package. During the work for a 2.2 release, I would also like to pull the audispd program inside auditd. In the past, I tried to keep auditd lean and single purpose, but with adding remote logging and kerberos support, we already have something that is hard to analyze. So, to improve performance and decrease system load, the audit daemon will also do event dispatching. Would this proposal impact anyone in a Bad Way?