Re: [Syslog] RE: byte-counting vs special character

Chris Lonvick <> Thu, 17 August 2006 14:34 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GDixQ-0006ls-SL; Thu, 17 Aug 2006 10:34:52 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GDixP-0006Qx-CM for; Thu, 17 Aug 2006 10:34:51 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GDikI-0002aW-Hd for; Thu, 17 Aug 2006 10:21:19 -0400
Received: from ([]) by with ESMTP; 17 Aug 2006 07:21:18 -0700
X-IronPort-AV: i="4.08,137,1154934000"; d="scan'208"; a="1848057942:sNHT30722452"
Received: from ( []) by ( with ESMTP id k7HELIdM022790; Thu, 17 Aug 2006 07:21:18 -0700
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id k7HELH6X020404; Thu, 17 Aug 2006 07:21:17 -0700 (PDT)
Date: Thu, 17 Aug 2006 07:21:16 -0700
From: Chris Lonvick <>
To: Balazs Scheidler <>
Subject: Re: [Syslog] RE: byte-counting vs special character
In-Reply-To: <1155817162.6514.27.camel@bzorp.balabit>
Message-ID: <>
References: <577465F99B41C842AAFBE9ED71E70ABA174DFB@grfint2.intern.adiscon.c om> <3EC76EAEC1590ED5FF81F03E@[]> <1155817162.6514.27.camel@bzorp.balabit>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
DKIM-Signature: a=rsa-sha1; q=dns; l=2028; t=1155824478; x=1156688478; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:Chris=20Lonvick=20<> |Subject:Re=3A=20[Syslog]=20RE=3A=20byte-counting=20vs=20special=20character;; b=psLprqoC+9rxUwKiyzw/72H8i08Sc7nSRr66jqgiL5uyaDDv4A9DKSHycrN7KKRTv/1wc9MT oPbZL0mQPs8mrR5dMvSH1EDNeO7GsLfU83iNNcMLUdYJ+N5BGnfnq+sv;
Authentication-Results:;; dkim=pass ( sig from verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


On Thu, 17 Aug 2006, Balazs Scheidler wrote:

> On Wed, 2006-08-16 at 12:32 -0700, Carson Gaspar wrote:
>> Escaping precludes no-configuration backwards compatibility, as no legacy
>> syslog-over-tcp code does escaping. So if you want to interoperate with
>> existing code, you must have a "don't escape or expect escapes" switch in
>> your code. If you're going to do that, just have a "LF mode vs byte-count
>> mode" switch. This whole backwards compat argument is bogus, iff we decide
>> to escape embedded LF instead of forbidding it. And I have yet to see
>> anyone argue for LF on any grounds except backwards compatibility.
> As I said in a private mail to you, no we don't need that switch. LF is
> escaped as a sequence of two characters '\' and 'n'. This way escaped LF
> characters will not affect protocol processing, the only issue is that
> LFs in the message will be written to the disk in a slightly different
> format. But adding the fact that current TCP senders are not transparent
> wrt LFs this is not a big deal.
> - old sender - new receiver
>    => works, because current syslog-TCP senders strip LFs off the
> message, either they replace it with space or forward multiple messages
> - new sender - old receiver
>    => works, because the old receiver does not care about the "\n"
> string in the message, although it will not unescape it when it writes
> it to disk

What's going to happen with syslog-sign and/or other mechanisms that will 
look at the packet and create a hash of it?  It sounds like everything 
will be acceptable if a new receiver gets it and does the re-conversion 
before anything looks at the contents.  However, an old receiver will 
continue to keep the \n which will mess up syslog-sign.  Is that correct?

Also, what's going to happen to a new receiver that receives a legitimate 
"\n" as in an original message send:
    <PRI>... BOM The offending characters are \n
Will the receiver convert that into LF?


Syslog mailing list