AcceptEnv LANG LC_* vs available locales

[Demi Marie Obenour]

On 4/27/22 05:40, Ingo Schwarze wrote:
> Hi Demi,
> 
> Demi Marie Obenour wrote on Tue, Apr 26, 2022 at 09:12:07PM -0400:
>> On 4/25/22 08:23, Ingo Schwarze wrote:
> 
>>> As discussed in the above writeup, the only way to make ssh(1)
>>> connections safe it to manually make sure, *before connecting*,
>>> that the same locale is set on both sides - ideally UTF-8.
> 
>> It is also safe for the locale to be different, so long as the
>> character encodings match.  For instance, all UTF-8 locales are
>> compatible.
> 
> Yes, that is what i meant.  In OpenBSD, we are used to the deliberate
> decision that the C library ignores all aspects of the locale except
> the character encoding, so the locale and the character encoding are
> one and the same and your statement is obvious for us.  Of course,
> your statement is also true on arbitrary other operating systems, even
> if they do take other parts of the locale into account.

Off-topic: Why did OpenBSD make this decision?  In particular,
LC_MESSAGES seems to be essential to internationalization support,
without being very problematic otherwise.

Also, is it safe if the server uses the C locale (LC_ALL=C) and the
client uses UTF-8?

> Thanks for making this aspect explicit.  You are right that it might
> not be obvious for users of other systems.

You’re welcome.

> That said, on non-OpenBSD systems, if the locale used by a program does
> not match watch the user thinks, the *semantics* of the program may still
> screw up horribly, even if the character encoding matches.  For example,
> consider user input of floating point numbers with LC_NUMERIC set to a
> cultural convention the user isn't aware of.  But such issues are
> only loose related to ssh(1) and to terminal security.

When it comes to terminal security, another approach is to use
a transient tmux(1) pane or terminal window that is closed once
the session is complete.  This assumes that the mismatch cannot be
exploited for code execution, but I would be highly surprised if it
could be, especially with the client in UTF-8 mode.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB288B55FFF9C22C1.asc
Type: application/pgp-keys
Size: 4885 bytes
Desc: OpenPGP public key
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220428/4b34c838/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220428/4b34c838/attachment-0001.asc>