OpenSSH banner doesnot display multibyte characters like korean

[Irek Szczesniak]

On Tue, Nov 27, 2012 at 2:54 PM, Bob Rasmussen <ras at anzio.com> wrote:
> I believe the standard multibyte encodings (Shift-JIS, Big-5, GBK, etc.)
> all avoid using bytes in the control character range (0x00 to 0x1F) for
> the second character.

I think they all have an ascii or ascii-like basis.
>
> Also, doesn't the SSH specification state that UTF-8 is the only allowable
> encoding for the banner?

In that case the PRC government will not allow openssh deployment for
government usage. GB18030 violations are NOT tolerated. The rules for
commercial software products in PRC are quite simple: you support
GB18030 or their government will shut your China branch down.
Permanently. There's no leeway for 'why?', 'if?' or 'can be have more
time?' (than the usual two months you get when they find out that you
violate their law).

>
> On Tue, 27 Nov 2012, Roland Mainz 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
>> [snip]
>>
>> 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[1] (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()|
>>
>> [1]=Erm... does anyone know how "Red Flag Linux" solved this ?
>>
>> ----
>>
>> Bye,
>> Roland
>>
>> --
>>   __ .  . __
>>  (o.\ \/ /.o) roland.mainz at nrubsig.org
>>   \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
>>   /O /==\ O\  TEL +49 641 3992797
>>  (;O/ \/ \O;)
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
>>
>
> Regards,
> ....Bob Rasmussen,   President,   Rasmussen Software, Inc.
>
> personal e-mail: ras at anzio.com
>  company e-mail: rsi at anzio.com
>           voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
>             fax: (US) 503-624-0760
>             web: http://www.anzio.com
>  street address: Rasmussen Software, Inc.
>                  10240 SW Nimbus, Suite L9
>                  Portland, OR  97223  USA
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



Irek