Phasing out forwarding of locale settings

[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.

See https://undeadly.org/cgi?action=article&sid=20160308204011
for details.

The situation with terminal emulators other than xterm(1) might be
even worse, but i suspect it is unlikely to be better.

Yours,
  Ingo