Short backstory: A server I've access to might have been hacked.  Due to
logrotate not being tweaked when the system was provisioned to keep more
than the default 4 weeks' worth of logs, it's hard to do a complete
forensics job.

Sure, this should have been done by the admin/s post-install, there's no
escaping that.  But logrotate with defaults set to retain more than 4 weeks
of log files all over /var/log might've helped discover how a system user
(with a uid < 1000) was added to this potentially hacked system in a
window of between 20-28 weeks ago.

On the system in question, excluding the systemd journal which contains
~700mb of noisy firewall logs, this is the size of both compressed and
uncompressed files:

  root@rescue /mnt/var/log # find . -type f |sed 's,^./,,g' \
  > |grep -v ^journal/ |xargs du -shc |grep total
  105M    total

Note: this figure also includes a decent amount of apache2 logs with the
usual 404s, 405s etc. that most web servers attract these days.

If three months' worth of logs were kept instead of just 4 weeks, I'd
guess due to compression ratios of text, that would come in at around
2-250M, if that.  It's not a lot of disk space in 2019, imnsho.

I'm expecting this bug to be closed, because it's not Debian's job to
set policies on log retention.  But I'm hoping maybe this bug can start
a discussion on whether longer retention periods should be an option,
maybe via a package configuration step or similar, so that the user
is reminded that they shouldn't always just fire and forget without
thinking about the what-ifs.  Hindsight's a wonderful thing...

Best,
Francis