On 4/25/22 08:23, Ingo Schwarze wrote:> Hi Harald, > > Harald Dunkel wrote on Mon, Apr 25, 2022 at 10:05:43AM +0200: > >> forwarding LANG and LC_* variables to the peer seems to be only >> reasonable, > > Absolutely not, what a terrible idea. > > For an introduction to the topic, see > > https://undeadly.org/cgi?action=article&sid=20160308204011 > > The end of that article specifically discusses ssh(1). > >> if the peer supports theses locales. Is there some >> workaround for this pitfall? Do you think the server could quietly >> ignore unknown locales? > > Ignore it? But if it does, then there is nothing it can safely do short > of rejecting the connection. > >> Every helpful hint is highly appreciated > > 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. -- 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/20220426/787b7327/attachment.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/20220426/787b7327/attachment.asc>
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