periodic security run output gives false positives after 1 year

[Martin Schütte]

On 17.02.2012 20:48, Roger Marquis wrote:
> and difficult to change without breaking more than it fixes.  The current
> syslog syntax timestamp has been reliable now for what, 25+ years?  I
> don't personally see any measurable ROI from changing it.  YMMV of
> course.

I really understand the concern, but some requirements do change over
time. Staying at the lowest common denominator for 25+ years may
indicate robustness, but it may also indicate obsolence.

I would like to ask a different question: what is our target? What kind
of logging infrastructure should a current operating system provide? And
how can we move forward toward that?

YMMV, but for me this target includes ISO timestamps, TLS network
transport, UTF-8 support, and more structured messages.
The IETF protocols are part of the solution, traditional BSD Syslog is
not enough.


A few more thoughts for the discussion:
 - with ISO dates it is easy to pipe logs through a timestamp-rewriting
perl script for older analysis tools. And some tools already support ISO
dates (for example the latest version of pflogsumm).

 - similar compatibility questions arise with UTF-8 data in logs.
syslogd(8) writes ASCII-only logs to ensure wide compatibility.

 - some admins (including myself) already moved to syslog-ng for these
two reasons: TLS transport and ISO timestamps.

 - regarding timestamps: I guess everyone with a long-term log archive
already has some year/month scheme, so IMHO the year is only a nice
bonus rather than a big feature. -- Bigger benefits are sub-second
resolution and timezone information (because with daylight saving time
even a standalone system spans two timezones).

 - in principle the NetBSD-current syslogd(8) even supports a per-target
configuration of old/new log format. But iirc this is not enabled,
because such a flag would add more clutter to the syslog.conf(5) syntax.

-- 
Martin Schütte