Re: get_field_str() and interpret_field() bug with multi-word fields

Steve Grubb wrote: I respectfully disagree. This is exactly the problem I trying to avoid. Once the log data is divorced from the user space tools necessary to correctly parse it there are going to be enormous problems. Let me be clear, I'm worried about the scenario where an audit log file was archived from some random system in MegaCorp, then many years later an auditor investigating MegaCorp decides that log file has critical information in it. Is MegaCorp going to be able to satisfy the regulatory requirements to correctly extract the audit data when the sys-admin who set up the logging left the company years ago, the information about the system has since been lost, the system has since been re-installed with a new OS, and no one bothered to archive the matching version of auparse with the log file? Don't forget, many auditing regulations require the raw log data to be preserved, not an interpreted version of the log data. This means one cannot just run auparse over the file to re-format it prior to archiving it unless one is willing to store two copies, the raw file and an interpreted version. People don't want to store two versions of data for obvious reasons. They want to store the raw data and correctly read it at any point in the future with one tool. The current scheme does not satisfy those requirements, nor is it scalable. I believe it's an absolute requirement that audit log files can be correctly parsed independent of any external information. -- John Dennis <jdennis(a)redhat.com&gt;