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 appreciatedAs 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. A special case of that rule is that with OpenBSD *and* the default OpenBSD xterm(1) configuration on the client side, it is always safe to connect to other OpenBSD machines, no matter the configuration on the server. But even with an OpenBSD client and the default xterm(1) config, connecting to other operating systems is never safe unless you make sure you have an ASCII or UTF-8 locale set on the server *before connecting*. Forwarding locale variables won't help with that at all. Yours, Ingo
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 Ingo, On 2022-04-25 14:23:06, 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. >I couldn't agree more, but please see the xterm packages on Debian and RedHat, and my related question about how to *undo* the SendEnv LANG LC_* in Debian's /etc/ssh/ssh_config in my .ssh/config. Anyway, the problem here is that MacOS sets a locale "UTF-8" in LC_CTYPE instead of "en_US.UTF-8", which produces problems even though UTF-8 is available on all involved systems.> For an introduction to the topic, see > > https://undeadly.org/cgi?action=article&sid=20160308204011 > > The end of that article specifically discusses ssh(1). >I highly appreciate your link, but for a Linux package maintainer it is too easy to ignore the problem. Maybe you should consider to add some guidelines about how to handle locales into a README within the openssh source package, or in ssh_config(5), sshd_config(5), etc.? Thank you very much Harri