Phasing out forwarding of locale settings

[Jochen Bern]

On 09.09.21 17:51, Alexander E. Patrakov wrote:
> 03.09.2021 20:02, Jochen.Bern at binect.de (Jochen Bern) пишет:
>> On 03.09.21 11:55, Florian Weimer wrote:
>>> 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?
>>
>> In order to achieve what exactly?
> 
> I would rather not forward the locale settings, and especially not
> accept them on the server side, and here is why.
> 
> More and more newbie Linux/cloud sysadmins use MacOS, not Linux, as
> their main system, and we have to deal with it. [...] Here is the
> default environment on a Mac running Big Sur:
> 
[...]> TERM_PROGRAM=Apple_Terminal
> LC_CTYPE=UTF-8
[...]
> 
> On Debian, the server-side configuration (minus comments) is as follows:
> 
[...]
> AcceptEnv LANG LC_*
[...]
> 
> So it accepts locale-related variables. Including this one:
> 
> LC_CTYPE=UTF-8
> 
> But, this is valid on MacOS only. It is not a valid locale on Linux, and
> will never be.

Most importantly (IMHO), that setting for a *language* env var fails to
indicate *a language* (or anything else that qualifies as localization).
Is there any locales support in MacOS, GUI excluded, in the first place?

> So, MacOS users that try to ssh to Debian systems will
> see locale errors (e.g. from Perl programs), and they often don't know
> why these errors appear and how to fix them.

My guess would be that we'll see Linux distribs do the equivalent of "ln
-s /usr/lib/locale/C.utf8 /usr/lib/locale/UTF-8" Any Day Now™ if MacOS
continues to throw that value around ...

One important point is that OpenSSH, as a trans-distrib upstream,
apparently *already does what you're asking*; the sshd_config manpage
says that "The default is not to accept any environment variables", even
on my CentOS systems, which come with

> # Accept locale-related environment variables
> 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

as *the distrib's* default config file content, and there is *no*
AcceptEnv to be seen in

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd_config?rev=1.104&content-type=text/x-cvsweb-markup

, not even commented out.

So, the ones you actually have to convince are the maintainers of
various distribs' OpenSSH packages. Who *might* have more interest in
that TheirOwnDistrib-to-TheirOwnDistrib logins work as usual,
*including* carrying the localizations along that work fine *there* ...

What you could ask for *here* is that OpenSSH stops supporting SendEnv /
AcceptEnv altogether - but I have a hunch that you'll need a much more
convincing case to get *that* thermonuclear solution.

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/20210909/c264e70d/attachment-0001.p7s>