Re: Unimplementability [was Re: adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers]

Mouse <[email protected]> writes:

> The basic problem is that various strings are specified as being UTF-8,
> but things in question are things that the systems in question don't
> store as character strings, but rather as octet strings.

Are you thinking only about usernames and passwords, or are there other
strings on the wire where this is a problem?

> This means
> that either an ssh implementation has to have some configuration switch
> telling it what the string encoding is in use or it will conform only
> if the local admins stick to UTF-8 for those things.

I think this is the right way, at least in theory. If you have non-ascii
usernames and passwords on your system, and want to accept logins from
remote systems, you can't expect any interoperability if you don't even
know what character set you are using. You'd have to either tell the
other end what you're using, or use some specific encoding on the wire
and convert locally. SSH chooses the latter approach, but the first
approach would have the same need for configurating what encoding to
advertise.

Not sure how big a hassle it is in practice.

> (In some cases
> it's conceptually possible to make the encoding setting user-specific,
> but in other cases, such as usernames, it's not.)

I guess in theory it's possible on a unix system to have different
user's use different character encodings for their passwords. I don't
see any good way to provide reliable interoperability in that case (and
no, I don't think it's a good solution to say passwords are octet
strings and it's the user's responsibility to figure out what the
corresponding characters are on each system; maybe we disagree here).

> In moussh's case, I chose to treat those things as opaque octet
> strings.  If the local system does not use UTF-8 for such things,
> moussh will not conform to ths spec.  (This is outlined in moussh's
> documentation, of course.)

I think it makes sense to have the default be either ascii or utf-8, and
with some option to let the sysadm override the default. And if you use
utf-8 for things like passwords (either by default or by configuration),
for reliable operation you ought to apply appropriate unicode
normalization on received passwords, possibly with another configuration
option to select the type of normalization.

> I don't know what implementations other than moussh do.

My implementation (lsh) isn't handling this very well, but I'll aim to
support at least ascii, latin-1, and utf-8 (nfc form, I think) as the
local character set.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.