OpenSSH banner doesnot display multibyte characters like korean
iszczesniak at gmail.com
Wed Nov 28 03:31:02 EST 2012
On Tue, Nov 27, 2012 at 2:21 PM, Roland Mainz <roland.mainz at nrubsig.org> wrote:
> On Tue, Nov 27, 2012 at 12:17 PM, balu chandra <balu9463 at gmail.com> wrote:
>> I did not come across any UTF8 implementation of strnvis.
>> Howver have modified strnvis() to display Multibyte char (tested the
>> fix with Korean char).
>> Though all calls to strnvis() could be extended to skip Multibyte char
>> this fix is limited to skipping only for Banner message(introduced a
>> flag for doing so).
>> The fix is provided here for comments.
>> [root at rhel62 bala]# diff -ur openssh6.1 openssh6.1_mod
>> diff -ur openssh6.1/openbsd-compat/vis.c openssh6.1_mod/openbsd-compat/vis.c
>> --- openssh6.1/openbsd-compat/vis.c 2012-11-27 16:12:23.986690241 +0530
>> +++ openssh6.1_mod/openbsd-compat/vis.c 2012-11-27 16:12:43.559859183 +0530
> Erm... the problem with this code is that it is specific to UTF-8
> only... but there are other multibyte encodings which are still in
> common use (like ja_JP.PCK/ShiftJIS on Solaris/Linux, both are used
> and mandated by goverment customers) and GB18030 (which is a) "modern"
> (e.g. not "legacy" like some people call the EUC encodings) and b)
> mandatory in PRC (China)).
> AFAIK a possible fix would be to pass the data through the libc
> multibyte functions and filter anything out which looks like the ASCII
> control characters (since more or less all multibyte characters have
> ASCII as basis) + anything which matches |iswcntrl()|
> =Erm... does anyone know how "Red Flag Linux" solved this ?
Red Flag Linux has disabled everything, including strnvis(), which
interfered with GB18030.
More information about the openssh-unix-dev