openssh unix dev - Sep 2021 - Phasing out forwarding of locale settings

[resending after subscribing, sorry for the possible duplicate]
03.09.2021 20:02, Jochen.Bern at binect.de (Jochen Bern)
?????:
> On 03.09.21 11:55, Florian Weimer wrote:
>> Most distributions send locale environment variables by default:
> [...]
>> And accept them on the server side:
> [...]
>> 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'm no stranger to putting "export LANG=C" into shell scripts
so that I
> can reliably parse command outputs, but on the other hand, our servers
> do document processing and some of the 3rd party software used will
> introduce strange misrepresentations unless we have both(!) en_US.UTF-8
> and de_DE.UTF-8 installed. Allowing the respective variables to be
> carried from client to server automatically keeps users from getting
> innovative with ~/.bashrc and the like ...
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. MacOS, by default, sends 
locale-related environment variables. Here is their default 
configuration in /etc/ssh/ssh_config, minus comments:

Host *
	SendEnv LANG LC_*

So, it will send locale-related environment variables. Here is the 
default environment on a Mac running Big Sur:

TMPDIR=/var/folders/sj/81q_d2g14f9_9_q5qp79yp3r0000gn/T/
__CFBundleIdentifier=com.apple.Terminal
XPC_FLAGS=0x0
TERM=xterm-256color
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.ofNlVbvqiZ/Listeners
XPC_SERVICE_NAME=0
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=440
TERM_SESSION_ID=220850B1-9079-4EC2-BE40-E5A79112F574
SHELL=/bin/zsh
HOME=/Users/user
LOGNAME=user
USER=user
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
SHLVL=1
PWD=/Users/user
OLDPWD=/Users/user
LC_CTYPE=UTF-8
_=/usr/bin/env

On Debian, the server-side configuration (minus comments) is as follows:

ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem	sftp	/usr/lib/openssh/sftp-server

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. 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. They would be better served 
by the Debian server applying its default locale settings. I even had to 
add some slides about this problem to my (proprietary and commercial) 
Linux sysadmin course, and would love to remove them.

-- 
Alexander E. Patrakov

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>