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? Thanks, Florian
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
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 ... 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/20210903/7e1fd030/attachment.p7s>