Hi,

one issue that is still to be addressed in aide is handling of logs that grow and then are immediately compressed away during initial rotation. This is, for example, what logrotate does when the "delaycompress" option is NOT set, as this is the case, for example, for the cron-apt, apt, aptitude, dpkg and xrdp packages in Debian. In this case, aide is unlikely to see the file after it has been last written to and before it has been compressed. Hence, the method of assigning the growing group to the log itself, full control to log.1 and full+compressed to log.2.gz and the following instances doesn't work for those logs.

Debian has documented this as "not supported" in the aide.config file that comes with the package, and a viable workaround is to locally add the delaycompress option to the respective logrotate configuration. But it would be better if aide would natively support that.

We have discussed this in private multiple times over the last years, and I am filing this issue so that we finally can put down ideas to solve this in a reproducible medium.

My idea would be to have a notation that puts the foo.1.gz compressed log somehow in relation to the foo log that is being written to, and to keep a copy of the foo file as it was seen during the last run somewhere for later reference. When aide then would see a foo.1.gz that doesn't fit the checksums we have in the database, it could decomress foo.1.gz and compare the beginning of the decompressed file with what it has saved. If equal, no report would be generated, the reference copy deleted and the checksums for the new foo.1.gz saved. This could be partly remedied by just saving a sha256 checksum for each block of 1 K data, with the price of not being able to checksum the last block because it is always incomplete. Or, save the checksums and the file length as seen.

I do agree that this is a very ugly solution that both needs a kind of notation that we never had before in aide (all aide rules currently stand for themselves and do not handle more than one file at a time), AND needs us to save non-trivial amounts of data.

But all of this is better than just saying "we're not going to monitor this since we can't".

Greetings, Marc