Subject: Re: finger
To: Jaromir Dolecek <firstname.lastname@example.org>
From: Noriyuki Soda <email@example.com>
Date: 09/12/2002 19:22:58
>>>>> On Thu, 12 Sep 2002 12:04:05 +0200 (CEST),
Jaromir Dolecek <firstname.lastname@example.org> said:
> 128-160 are control characters in iso-8859-*, so they are not safe
> to pass without character set protocol extension.
I know. (Didn't I say I know your intention? :-))
But as I said, Because of both the RFC and practical reason, we
should have an option to support values 128-160.
So, original patch (which is now in our repository) is wrong.
>> Default should be defensive, shoudn't it?
> I'd be interested to know about 'smaller' cases. Surely there
> are 'larger' ones (like windows-1250, koi8, euc-*, etc), which
> have printable characters in 128-160 range, but I'm not aware
> of character set with control characters in range 161-255.
> Yes. Default of passing 33-127, 161-255 (in both finger and fingerd)
> is as defensive, interop-friendly and convenient as we can get.
I guess that is not defensive enough.
Think about the following case:
- Assume an implementation which supports multibyte codeset.
- The implementation has some problems. For example, the
implementation don't check value range of the second byte
of multibyte characters.
- Assume a server replies the following two Latin-1 characters.
(Note that this sequence is completely valid with Latin-1):
character 10 (i.e. newline)
- The value 161 is a first byte of 2byte character sequence
with the above (problematic) multibyte codeset implementation.
- The implementation should check that the second byte 10 is not
a valid code as a second byte, but the reality is that
the implementation doesn't check it. Thus, the
implementation crashes with the above Latin-1 sequence.
So, your SAFE default may be able to crash some client implementation.
i.e. Your assumption is not safe enough.
Just like 128-160 are not safe enough to pass without character set
protocol extension, 161-255 are also not safe enough to pass.
Do people now understand why itojun said the change is not right at
the first place? :-)