openssh unix dev - Apr 2022 - AcceptEnv LANG LC_* vs available locales

On 27.04.22 21:48, Thorsten Glaser wrote:
> On Wed, 27 Apr 2022, Harald Dunkel wrote:
>> Maybe you should consider to add some guidelines about how to handle
>> locales into a README within the openssh source package, or in
>> ssh_config(5), sshd_config(5), etc.?
> 
> Pretty easy: handle them on the server, period. There?s no way to
> do it otherwise.
Sure, because "have server setting blindly trump clients'" is *so*
much
better than "have client setting forwarded blindly to the server".

And here I thought that, after OpenVPN painstakingly retrofitting one 
into their data channel setup, "when you need an agreement, you need an 
explicit negotiation phase" would be a commonly accepted tenet now ...

(As in, *let* the client send his settings, then have the shell's 
startup phase run a helper application that edits the env vars as 
necessary to achieve compatibility with the server's capabilities.)

Regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220428/bd64e3a0/attachment-0001.p7s>

Hi Jochen,

Jochen Bern wrote on Thu, Apr 28, 2022 at 08:53:32AM
+0200:
> On 27.04.22 21:48, Thorsten Glaser wrote:
>> On Wed, 27 Apr 2022, Harald Dunkel wrote:
>>> Maybe you should consider to add some guidelines about how to
handle
>>> locales into a README within the openssh source package, or in
>>> ssh_config(5), sshd_config(5), etc.?
>> Pretty easy: handle them on the server, period. There?s no way to
>> do it otherwise.
> Sure, because "have server setting blindly trump clients'" is
*so* much
> better than "have client setting forwarded blindly to the
server".
> 
> And here I thought that, after OpenVPN painstakingly retrofitting one 
> into their data channel setup, "when you need an agreement, you need
an
> explicit negotiation phase" would be a commonly accepted tenet now ...
This would be a nice to have if it were possible.
But calling an impossible task "a commonly accepted tenet"
feels unwise to me.
> (As in, *let* the client send his settings, then have the shell's 
> startup phase run a helper application that edits the env vars as 
> necessary to achieve compatibility with the server's capabilities.)
And if the client says they want "zh_CN.UTF-16" but the server only
knowns how to do "C" and "en_US.UTF-8", then what are you
going to do,
as just one example among a host of tricky combinations?  In fact,
the only safe option in such a situation is to reject the connection.

And even if a safe setting existed in every case, which it does not,
it would be a complex and open-ended task to figure out what that setting
is on a given machine to be compatible with an arbitrary locale name
received over the wire, since POSIX explicitly says that the meaning
of locale names (apart from "C" and "POSIX") is
implementation-defined.

So for every operating system and every possible subset of locales that
might be installed on a server, OpenSSH maintainers would have to maintain
a list of how to best match *any* valid locale from *any* other system to
one of the locales available on the server.  Even in ideal circumstances,
that's a nightmarish task that can never be completed but is highly
error-prone.  Even if somebody would be willing to do all that work,
having complex scripts or helper applications called at this stage would
cause a security concern by adding attack surface.

Besides, in this world, circumstances are rarely ideal.  In theory,
the same locale name might even refer to different locales on different
systems.  Maybe even in practice: for example, "C" used to refer to an
effectively ISO-Latin-1 locale on old releases of OpenBSD (it no longer
does).  It's an ugly memory even though reasons existed to do that.
Users might even install their own, personal locale, so a locale string
might even indicate a locale that is non-standard even for the operating
system the client happens to be running...

Sure, any magic scheme you might devise to achieve the above would
likely work in many cases, so users would get trained into an utterly
unsafe attitude of "locales just work with SSH" and stop thinking
about it.  If the beast would then suddenly bite, it would bite all
the deeper.


In conclusion, i think it is better to take a firm stand and say:

  It is purely the responsibility of the user to make sure that
  the server locale and the client locale are compatible *before
  connecting*.  Otherwise, all bets are off.  Ideally, use UTF-8
  on both sides *and* make sure your xterm(1) runs in UTF-8 mode.

Yours,
  Ingo

On 28.04.22 11:05, Ingo Schwarze wrote:
> Jochen Bern wrote on Thu, Apr 28, 2022 at 08:53:32AM +0200:
>> And here I thought that, after OpenVPN painstakingly retrofitting one
>> into their data channel setup, "when you need an agreement, you
need an
>> explicit negotiation phase" would be a commonly accepted tenet now
...
> 
> This would be a nice to have if it were possible.
> But calling an impossible task "a commonly accepted tenet"
> feels unwise to me.
It was not "impossible" for the developers of OpenVPN, and those did 
*not* have the advantage of one side *already* havind a mechanism to 
pass the pertinent information to the other, like OpenSSH does with the 
env var forwarding for the (client side) locales.
> And if the client says they want "zh_CN.UTF-16" but the server
only
> knowns how to do "C" and "en_US.UTF-8", then what are
you going to do,
> as just one example among a host of tricky combinations?  In fact,
> the only safe option in such a situation is to reject the connection.
If that's your opinion, go ahead and implement it. Which my suggestion 
of a server-side helper evaluating the client-side-set and 
server-side-available locales for *some* decision *does* support. It 
actually even allows you to send back a US-ASCII error message *telling* 
the user what the problem is before summarily kicking him out. But don't 
expect the rest of the planet to join you in waiting for the *perfect*, 
totally loophole-free solution you seem to insist on.

Which is not to say, mind, that such a thing will not come EVENTUALLY. 
Unicode seems well-poised to prove being the end-all complete framework 
for transmitting and outputting texts, short of quipus or a first 
contact situation; I expect terminals to gravitate more and more towards 
implementing it, increasing the pressure on the consortium to include 
two codepoints to "shift to control" and "shift back" into
its
standards, laying the groundwork of a *global* algorithm for terminals 
to tell control data from content.

(And considering that easily more than half of the control sequences 
*do* have an effect on the rendering of the "printable" text, who says
that standardizing them in their entirety is forever outside the 
consortium's purview, even?)

But no guarantees that any of that is going to come full circle within 
any present company's lifetimes, though. Hence the question what *we* 
can do to improve the situation, if only partially.
> And even if a safe setting existed in every case, which it does not,
> it would be a complex and open-ended task to figure out what that setting
> is on a given machine to be compatible with an arbitrary locale name
> received over the wire, since POSIX explicitly says that the meaning
> of locale names (apart from "C" and "POSIX") is
implementation-defined.
That situation is, however, not going to improve if you go and tell 
everyone that "it's nobody else's business" if they choose to
keep
inventing their very own locale XY_??? for language XY. And the way it 
is right now, chances are that such maintainers will *never even hear* 
about the interoperability problems they cause. Even if an interop 
standards project (like one to write said helper) cannot *solve* 
everything, it can at least *demonstrate* that XY_??? causes 
significantly more problems that XY_ok, and *why* that is.
> So for every operating system and every possible subset of locales that
> might be installed on a server, OpenSSH maintainers would have to maintain
... absolutely nothing. SSH is merely the means connecting a terminal 
(some device to present "printable" data) to a - likely remote - 
shell/application (producing such data), and can be replaced by pretty 
much everything from ye olde serial cable to whatever post-quantum 
communications protocol minimizes in-transit bit decay by Dark Energy. 
All that is required from OpenSSH is to transport the information "this 
is a remote connection" and "these are the other side's
capabilities",
and setting the SSH_* and LC_* env vars on the server side already does 
that nicely.

I'm using the term "(external) helper" instead of "code (to
be
integrated into OpenSSH)" for a *reason*, you know.
> Users might even install their own, personal locale, so a locale string
> might even indicate a locale that is non-standard even for the operating
> system the client happens to be running...
Well, breaking interoperability between "themselves" (user and their
DIY
software) and their *own* computer should teach them to be wary of 
distribs that do not bother about cross-platform interop *real* fast ...

... hmmm, I wonder, would they actually be able to vote with their feet 
and install a port of a better-interop locale from another distrib over 
an isolationist one that came with their locally installed distrib ... ?
> Since they have a german locale set on the the
> client side, they type "ja" when the program on the server asks
whether
> they really want to delete the file.  But the server does not have a
> german locale installed, so "ja" actually means "no",
the file remains,
> and the secret information is accidentally disclosed without the poor
> user even suspecting something might have gone wrong.
Fine, let's assume for a moment that being prompted with
> Effacer le fichier ULTRAGEHEIM.txt? [o/N] _
fails to inform the user that the server is not exactly talking German 
to him. Let's further assume that we're not talking about a yes/no 
decision (FYI, I would still have to find a German localization asking 
"j/N ?" that would not also accept the C/English "y" for a
"yes"), but
something that's not as trivial to translate - say, the user enters an 
amount thinking of ? but the software takes it as ?.

Now how is *that* an argument in *favor* of your proposal of having the 
server *downright ignore* the locale the user has tried to set!? A user 
*that* dependent on a never-changing interface, and robbed of the option 
of adapting the server's setup, would need to have a dedicated immutable 
server to use for the rest of his (work)life. (Preferably one that still 
accepts amounts in DM instead of ?, I suppose.)

Regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220501/606196f7/attachment-0001.p7s>