openssh unix dev - Apr 2022 - AcceptEnv LANG LC_* vs available locales

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.

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

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.

Yours,
  Ingo

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>