Re: AcceptEnv LANG LC_* vs available locales

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux