Subject: Bug#566: [X2Go-Dev] Bug#566: X2Go Client for Windows 4.0.2.1 cannot create C:\Users\<username>\ssh\known_hosts file when the local Windows account username has non-Ascii characters

From: Michael DePaulo <[email-masked]>
Date: Tue, 9 Sep 2014 09:15:52 -0400

On Mon, Sep 8, 2014 at 4:58 AM, Mike Gabriel
<[email-masked]> wrote:
> Hi Mike#2,
>
>
> On  So 07 Sep 2014 15:23:22 CEST, Michael DePaulo wrote:
>
>> On Sun, Sep 7, 2014 at 6:04 AM, George Trakatelis <[email-masked]>
>> wrote:
>> [...]
>>>
>>>
>>> a. Installed German keyboard. Hit ';' to produce an accented letter
>>> and -to my surprise- got ö. So I thought ölexandr was the right name to
>>> test for username.
>>>
>>> b. Created user ölexandr and logged in as that user.
>>> The patch did not work, as you mentioned.
>>>
>>> c. As toLocal8Bit() returns the local 8-bit representation of a string,
>>> I changed the system locale for non-unicode programs to German.
>>> Now the patch worked!
>>>
>>> I think the patch solves the problem for the Windows users who use
>>> English
>>> as a foreign language and prefer having (non-Ascii) usernames in their
>>> native language.
>>>
>>> -George
>>>
>>> PS. A better title for the bug would be
>>>
>>> X2Go Client for Windows 4.0.2.1 cannot create
>>> C:\Users\<username>\ssh\known_hosts file when the local Windows account
>>> username has non-Ascii characters
>>
>>
>> Hi Mike#1 and George,
>>
>> 1. What do you think of using toUtf8() instead? I am hoping that will
>> fix the bug regardless of the locale.
>>
>> I tried changing it to that (bug566.utf8.test.patch), but it still did
>> not fix this bug with the greek username on my system with the locale
>> set to English. It did not introduce a regression for my ASCII user
>> account at least.
>>
>> If libssh needs to be recompiled for Unicode, I can do that. I just
>> recompiled it for bug #590.
>>
>> FYI: This is the API we are calling:
>>
>> http://api.libssh.org/stable/group__libssh__session.html#ga7a801b85800baa3f4e16f5b47db0a73d
>
>
> I am getting the suspicion, that this is a libssh issue.
>
> X2Go Client and libssh should communicate via UTF-8 (because it is _the_
> encoding that applications use internally, nowadays) and libssh should
> handle whatever conversion (probably to UTF-16 wide string?) is necessary
> for creating files, being aware of usernames, etc.
>
>> 2. in sshmasterconnection.cpp, we also set "SSH_OPTIONS_USER" . I
>> think that we should also change its value from to.Ascii() to
>> toLocal8Bit() or toUtf8(). bug566.test.v2.patch has this change for
>> toLocal8Bit(), and bug566.utf8.test.patch has it for toUtf8().
>
>
> Same thing. SSH_OPTIONS_USER should be set as UTF-8 and libssh should
> convert to whatever encoding is needed.
>
> Greets,
> Mike
[...]

Hi Mike#1 and George,

1.

I believe the best approach is to try to compile libssh with unicode
support, and pass unicode values to it. There is no guarantee that a
user's username (and home dir path) is in the same language as the
language that is set for non-Unicode programs. After all, the
"Language for non-Unicode programs" is called the "system locale", it
applies to all users on the system.

If we have to for the 4.0.3.0 release of x2goclient, we should fix
this bug for the system locale only, and then fix the bug for all
languages/locales later.

2.

See bug 474 for George's patch for compiling libssh with MinGW 4.8.2.
It worked :)

3.

I made some progress compiling libssh 0.6.3 with Unicode support.

With MinGW 4.4, when I specified the following values in CMAKE, libssh
built successfully, but it did not seem to change anything.
CMAKE_EXE_LINKER_FLAGS:STRING=-municode
CMAKE_MODULE_LINKER_FLAGS:STRING=-municode
CMAKE_SHARED_LINKER_FLAGS:STRING=-municode
CMAKE_STATIC_LINKER_FLAGS:STRING=-municode

With MinGW 4.8.2, when I specify those values, libssh fails to build.
I've attached the output.

This is a positive sign because it implies that MinGW 4.8.2 supports
-municode, whereas MinGW 4.4 did not.

I plan to try to resolve this build failure later tonight.

-Mike#2