Anton: > I can see something like this error message: > > ...MyApp pid123 MALFORMED_INPUT: Bad input received from > client: [aaa\u0000] > > The question is does not it need to be escaped for transport > or only in display. I'd personally prefer deferring any kind > of escaping until it is really needed, like when displaying > binary to the user.
I agree it can be a valid character. Also note that we (quickly at that time) went over this topic in the past and agreed that we would need to support NUL. My point is a different one. I have begun to look at the draft from the implementors point of view. Especially from the view of someone who want's to upgrade an existing syslogd implementation to syslog-protocol. One goal of such a person would definitely to do it with as less effort as possible. The issue is that many syslogds are written in C/C++. NUL is used as string terminator. I can back this by testing. If I send NUL characters embedded inside the message, almost all existing syslogds terminate the message text at this point. (side-note: I am currently thinking about if that is a security vulnerability in almost all syslogds). If you want to upgrade an existing syslogd to support NUL you can do one of two things: #1 rewrite your syslogd so that it uses byte-counted strings and not the C RTL string functions #2 replace the NUL with an escape, e.g. \0 or <00> #1 would obviously be the best choice (also from a security point of view). I just doubt that many implementors will accept the (considerable) effort required. I think that most will resort to #2. #2 must be done early, right after message reception (else you already deal with C-strings). So when it comes to relaying, the orginal message will not be preserved (side note: it will also not be preserved when writing to a file). That means that digital signatures (syslog-sign) will be broken. While I see this is an implementation issue (not a protocol one), I also see that allowing NUL will almost ask for this common implementation "error". It would also render all efforts in regard to syslog-sign useless. 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). Rainer > > Thanks, > Anton. > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Ross > > Sent: Wednesday, November 23, 2005 6:17 PM > > To: 'Rainer Gerhards' > > Cc: [EMAIL PROTECTED] > > Subject: RE: [Syslog] New direction and proposed charter > > > > > > >The only tricky issue that remains is the NUL octet. The > > more I think > > >about it, the more I think the CLR to disallow it is less > > evil than to > > >make it stay... > > > > I agree that having the CLR for NUL octet exclusion is OK. > > > > Quick question, if someone is sending international data in > > UTF-8 format, can there ever be a valid UTF-8 sequence that > > includes a NUL octet value? If so, we need to allow NUL > > values in the MSG. > > > > Does anyone on the list know UTF-8 well enough to answer this? > > > > Cheers > > > > Andrew > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
