From owner-freebsd-security@FreeBSD.ORG Sat Feb 18 01:10:40 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEB9F1065676 for ; Sat, 18 Feb 2012 01:10:40 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6893B8FC1E for ; Sat, 18 Feb 2012 01:10:39 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 4C7B128433; Sat, 18 Feb 2012 02:10:37 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id CB0832842D; Sat, 18 Feb 2012 02:10:35 +0100 (CET) Message-ID: <4F3EFA8B.50002@quip.cz> Date: Sat, 18 Feb 2012 02:10:35 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Roger Marquis References: <20120217120034.201EB106574C@hub.freebsd.org> <20120217152400.261AC106564A@hub.freebsd.org> <20120217194851.D76DE1065670@hub.freebsd.org> <4F3EE1C9.4030601@quip.cz> <20120217235620.4BEF4106566B@hub.freebsd.org> In-Reply-To: <20120217235620.4BEF4106566B@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, Sergey Kandaurov Subject: Re: periodic security run output gives false positives after 1 year X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 01:10:40 -0000 Roger Marquis wrote: >>> 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. >> >> It is similar to y2k problem and dates with YY format instead of YYYY >> - it was fine for many years... > > Is it? If I recall Y2K had more to do with 2 digit year fields that should > have been 4 digit. > >> But did you noticed, that almost everything else is already logging >> with year in date? > > I don't personally recall a time when everything else wasn't logging the > year, in one format or another. That's not to imply that syslogs > shouldn't be distinguishable by year but the question seems to be where > the year should be logged, A) on every line or B) in the archive file > name. The problem is, that filename can be easily changed by mistake and then you can't tell, what date you have stored in file. > I suspect it was not common practice to leave logs on the server for more > than a year when Allman originally wrote syslog, and I have not seen an > environment where logs are left in /var/log for over a year. Personally, > I would rather see FreeBSD stay backwards compatible and A) leave the > syslog timestamp format alone instead opting for KIS by simply writing > the year in the archive file name rather than wasting 5 bytes on every > line of every syslog log file. YMMV. I understand your point of view, but very little in FreeBSD is (and will be forever) backward compatible. It is an evolution. And if we are talking about space - FreeBSD installation doesn't fit floppy disk drive for a long time :) Just for curiosity - logs are stored mostly in compressed state and there is almost no difference in size of compressed file if there is four digits year or not. I did a quick test where I changed "Feb 15 01:52:06" to "2012-02-15 01:52:06" format. 2.8M auth.log.orig 3.0M auth.log.newdate 284K auth.log.orig.gz 284K auth.log.newdate.gz 76K auth.log.orig.bz2 78K auth.log.newdate.bz2 As you can see, there is 0.2M difference in plain text, but with gzip, there is no difference, with bzip2 there is only 2KB more. Again - I understand your view, but I still think that using new ISO date format is an improvement. Cheers, Miroslav Lachman