Subject: Re: finger
To: None <jdolecek@netbsd.org>
From: T.SHIOZAKI <tshiozak@astec.co.jp>
List: tech-userlevel
Date: 09/12/2002 23:19:59
From: Jaromir Dolecek <jdolecek@netbsd.org>
Subject: Re: finger
Date: Thu, 12 Sep 2002 11:31:18 +0200 (CEST)
Message-ID: <200209120931.g8C9VII00752@s102-n054.tele2.cz>

> (note I didn't look at Kimmo's change, I don't have reason to believe
> it's not right)
> 
> T.SHIOZAKI wrote:
> > I got several comments about it and explained about them.
> > I intend to wait for one day again.
> > If there is no other significant objection, I will commit it tomorrow.
> 
> At the very least, please don't call the macros 'ascii_something()',
> since ASCII only covers 0-127.

Surely, these macros should be called after the zone is checked.

Also, ascii_isascii() is redundant.  Fortunately, isascii() defined
in ctype.h is available in this case.

I explained why ascii_isspace() and ascii_isprint() are needed.


> And please make sure to not pass values 128-160 (which map
> to control characters on 7bit displayes, and are assigned as 'control
> characters' in iso-8859-* character maps for this reason).
>
> I also think that it should be default to pass the 161-255 characters
> in both finger and fingerd, and I don't think it's necessary to
> have an option to switch this off.

Such issues have already been almost settled.

  - Such safety check should be done by client side in principle.

  - Our finger and fingerd had been restricted within ASCII
    printable characters.
    I think this restriction should be leaved for the backward
    compatibility and keeping perfect safeness, although some
    people seems to think not so.
    There is a little difference of opinion.

  - To apply to rfc1288, 0x00-0x1F characters are always rejected
    by fingerd.  fingerd may also need to reject 0x80-0xFF characters.

  - finger can pass the non-ASCII characters by option if needed.
    In this case, the user can choose one of:
      - finger uses isspace() and isprint() to judge whether the character
        is printable.  The responsibility to keep consistency between the
        terminal and the locale setting rests with the user.
        This mode can be used for single byte locales only.
      - All 0x20-0x7E, 0x80-0xFF characters are passed to the terminal.
        All responsibilities rest with the user.
    There is also a little difference of opinion how to switch them.


> IMHO aiming for protocol change is neat, but totally unrealistic.

I think so.  The reason why we have been discussing long time
is to find a realistic solution to satisfies some people's wishes.


...Actually, Kim's most recent fix seems not so bad for me,
except for a few points.
At least, finger should stop calling nl_langinfo().

# As a implementator of the current i18n framework of libc,
# how to use the isxxx() functions still worries me, of course...


--
Takuya SHIOZAKI / ASTEC Products, Inc.