Phasing out forwarding of locale settings

[Florian Weimer]

* Ingo Schwarze:

> Hi Florian,
>
> Florian Weimer wrote on Fri, Sep 03, 2021 at 11:55:54AM +0200:
>
>> Most distributions send locale environment variables by default:
>> 
>> SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
>> SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
>> SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
>> SendEnv XMODIFIERS
>> 
>> And accept them on the server side:
>> 
>> AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
>> AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
>> AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
>> AcceptEnv XMODIFIERS
>> 
>> (Some distributions also use LC_* wildcards.)
>> 
>> Now that servers often use minimal installations which only support a
>> small set of locales (C, C.UTF-8), would it make sense to discontinue
>> this practice?
>
> I think the question is moot.  Fiddling with this is at best lipstick
> on a pig.  There is only one way to make remote shells safe, and
> it is not specific to SSH.  It requires that *both* of the following
> necessary conditions be observed:
>
>  1. Make sure your xterm(1) is set to UTF-8 mode.  Yes, using UTF-8
>     mode is critical even when you want to actually use US-ASCII only.
>     Traditional 8-bit mode cannot be made safe with any locale.
>
>  2. Make sure that on each side, either the POSIX locale or an UTF-8
>     locale is in use; it is not necessary that they match.  Using any
>     other locale on either side is not safe.

We increasingly see a situation where the terminal has some UTF-8 locale
(usually en_US.UTF-8), but the remote end does not recognize that and
falls back to the POSIX locale, often quite noisily.

This configuration matches your safety criteria, but the user experience
is still poor.

Thanks,
Florian