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
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 ¥.Effacer le fichier ULTRAGEHEIM.txt? [o/N] _
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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
