Subject: RE: [Syslog] New direction and proposed charter

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 24 Nov 2005 10:24:30 +0100

> On Thu, 2005-11-24 at 09:36 +0100, Rainer Gerhards wrote:
> > Anton: 
> 
> > So I wonder if it wouldn't be wiser to accept that CLR here 
> and disallow
> > NUL. After all, I can not see a valid use case for it 
> either... (in the
> > sample you provided it honestly believe the sender should 
> not send a NUL
> > octet but a "\u0000" string).
> > 
> 
> \u0000 is a NUL octet at least in its canonical encoding. 

OK, looks like I need to dig up the ASCII table. My fault I didn't do it
in the first place.

Anston's sample was

 ...MyApp pid123 MALFORMED_INPUT: Bad input received from client:
[aaa\u0000]

For simplicity, let me strip the rest and just look at that part

\u0000

I think the sender of the sample message should not encode it as

NUL (0x00)

but instead as

0x5c-0x75-0x30-0x30-0x30-0x30 (\-u-0-0-0-0)

Encoding it as NUL in an otherwise human-readable message makes no sense
to me. 

I am questioning if there is any legitimate case where an actual NUL
needs to be part of MSG.

> UTF-8 allows
> the same character to be encoded in multiple ways, see a 
> description on
> the encoding format:
> 
> http://www1.tip.nl/~t876506/utf8tbl.html
> 
> And I think it would be wise to require the canonical encoding to be
> used and treat all other encodings of the same characters as errors.
> this is a large can of worms, lot's of security problems arised from
> this issue. (see the IIS problems couple of years ago)

"Shortest possible form" thanksfully is already required in
syslog-protocol-15.

Rainer

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Balazs Scheidler <[email-masked]>
Date: Thu, 24 Nov 2005 15:12:16 +0100

> I am questioning if there is any legitimate case where an actual NUL

Now I understand, and we perfectly agree. I don't see a reason to
include 0x00 octet. In fact syslog-ng filters everything below 32, to
avoid nasty tricks with escape sequences in the log files viewed. Though
this could be opened up a bit if needed.

-- 
Bazsi