Mailing List Archive

AcceptEnv LANG LC_* vs available locales
Hi folks,

forwarding LANG and LC_* variables to the peer seems to be only
reasonable, if the peer supports theses locales. Is there some
workaround for this pitfall? Do you think the server could quietly
ignore unknown locales?

Every helpful hint is highly appreciated

Harri
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On 2022/04/25 10:05, Harald Dunkel wrote:
> Hi folks,
>
> forwarding LANG and LC_* variables to the peer seems to be only
> reasonable, if the peer supports theses locales. Is there some
> workaround for this pitfall? Do you think the server could quietly
> ignore unknown locales?

I think it would be too much magic if the SSH server considered the
contents of these variables. Apart from anything else, it doesn't know
whether particular software that you might be running in SSH might need
some setting that sshd doesn't know about.

If you're using non-default config to pass these variables and have
some places where it's a problem to see an unknown locale, you could
always make your own changes to the variables in .profile on those
systems. (I am guessing that in the majority of these cases the only
actual problem is the noise from Debian's Perl configuration...)

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
Hi Stuart,

On 2022-04-25 10:25:19, Stuart Henderson wrote:
>
> If you're using non-default config to pass these variables and have
> some places where it's a problem to see an unknown locale, you could
> always make your own changes to the variables in .profile on those
> systems. (I am guessing that in the majority of these cases the only
> actual problem is the noise from Debian's Perl configuration...)
>

Indeed.

I think the easiest and most consistent way is to *not* send LANG
and LC_CTYPE and the others to the peer. I have a related question
to SendEnv in ssh_config(5):

Does
Host debianhost
SendEnv !LANG !LC_*

tell ssh to ignore the previous

SendEnv LANG LC_*

set in /etc/ssh/ssh_config, or does it mean to send *all* variables
except for LANG and LC_*? Maybe I am too blind to see, but the man
page appears to be a bit vague in this case.


Regards
Harri
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
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.

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
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)
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
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@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On 2022/04/27 12:14, Harald Dunkel wrote:
> 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.

SendEnv is additive, it does not replace existing config when you list
a new variable, instead it adds to the existing variables.

So all you can do is add a variable, or remove a variable which was
_already_ set earlier in parsing, not prevent one from being set in later
parsing.

According to the manual, the config files are parsed in this order:

1. command-line options
2. user's configuration file (~/.ssh/config)
3. system-wide configuration file (/etc/ssh/ssh_config)

So, as far as I can tell, you will need to remove the existing entry
from /etc/ssh/ssh_config, there's no other way to override it.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
Hi Stuart,

On 2022-04-27 12:47:14, Stuart Henderson wrote:
> On 2022/04/27 12:14, Harald Dunkel wrote:
>> 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.
>
> SendEnv is additive, it does not replace existing config when you list
> a new variable, instead it adds to the existing variables.
>

The man page points to the "PATTERNS" section in this context, so
how about

SendEnv !LANG !LC_*

or something similar?


Regards

Harri
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On 2022/04/27 13:08, Harald Dunkel wrote:
> Hi Stuart,
>
> On 2022-04-27 12:47:14, Stuart Henderson wrote:
> > On 2022/04/27 12:14, Harald Dunkel wrote:
> > > 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.
> >
> > SendEnv is additive, it does not replace existing config when you list
> > a new variable, instead it adds to the existing variables.
> >
>
> The man page points to the "PATTERNS" section in this context, so
> how about
>
> SendEnv !LANG !LC_*
>
> or something similar?

Try it if you like, it's very simple to test, but from my understanding
it's not going to help.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On 2022-04-27 13:16:04, Stuart Henderson wrote:
> On 2022/04/27 13:08, Harald Dunkel wrote:
>> Hi Stuart,
>>
>> On 2022-04-27 12:47:14, Stuart Henderson wrote:
>>> SendEnv is additive, it does not replace existing config when you list
>>> a new variable, instead it adds to the existing variables.
>>>
>>
>> The man page points to the "PATTERNS" section in this context, so
>> how about
>>
>> SendEnv !LANG !LC_*
>>
>> or something similar?
>
> Try it if you like, it's very simple to test, but from my understanding
> it's not going to help.
>

I meant, how about extending SendEnv to support something like

SendEnv !LANG !LC_*

to explicitly forbid sending variables with a matching name to
the peer? This could help to override the settings in /etc/ssh/ssh_config.

Another option to add could be to disable sending variables completely
(except for TERM).

AFAICT it is pretty uncommon, that the default configuration for some
user application (/etc/ssh/ssh_config) cannot be overridden in the user's
config file. What would you suggest to get out of this mess? Ditch all
Linux distros with a broken ssh_config file, plus MacOS? alias ssh=\
"ssh -F /dev/null" ?


Regards

Harri
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On Wed, 27 Apr 2022, Harald Dunkel wrote:

> 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.

That’s the name of the UTF-8 locale on recent OSX, yeah. Caused
quite a few “WTF” looks. It loosely corresponds to “C.UTF-8” ever
since the Debian (e)glibc maintainers accepted my proposal for it
(MirBSD also basically only has the UTF-8 and ASCII locales, so it
was natural to propose a C.UTF-8 for GNU stuff) around 2013 or so.
Some systems have “en_US.UTF-8”, some “en_US.utf8” (HP-sUX!), and
again some only have, say, “de_DE.UTF-8” but not the latter two
(hence the introduction of C.UTF-8).

> 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.?

Pretty easy: handle them on the server, period. There’s no way to
do it otherwise.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

****************************************************
/?\ The UTF-8 Ribbon
? ? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
 ?  HTML eMail! Also, https://www.tarent.de/newsletter
? ? header encryption!
****************************************************
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On 2022-04-27 21:48:07, Thorsten Glaser wrote:
> On Wed, 27 Apr 2022, Harald Dunkel wrote:
>
>> 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.?
>
> Pretty easy: handle them on the server, period. There’s no way to
> do it otherwise.
>

I would love to, but please see this:

https://bugs.debian.org/965323
https://bugs.debian.org/952516

Anyway, the idea is to add an official statement like Ingo's

"SendEnv LANG LC_*" is a terrible idea

into the source files to take influence upon the package managers.


Regards

Harri
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On 27.04.22 21:48, Thorsten Glaser wrote:
> On Wed, 27 Apr 2022, Harald Dunkel wrote:
>> 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.?
>
> Pretty easy: handle them on the server, period. There’s no way to
> do it otherwise.

Sure, because "have server setting blindly trump clients'" is *so* much
better than "have client setting forwarded blindly to the server".

And here I thought that, after OpenVPN painstakingly retrofitting one
into their data channel setup, "when you need an agreement, you need an
explicit negotiation phase" would be a commonly accepted tenet now ...

(As in, *let* the client send his settings, then have the shell's
startup phase run a helper application that edits the env vars as
necessary to achieve compatibility with the server's capabilities.)

Regards,
--
Jochen Bern
Systemingenieur

Binect GmbH
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
Hi Jochen,

Jochen Bern wrote on Thu, Apr 28, 2022 at 08:53:32AM +0200:
> On 27.04.22 21:48, Thorsten Glaser wrote:
>> On Wed, 27 Apr 2022, Harald Dunkel wrote:

>>> 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.?

>> Pretty easy: handle them on the server, period. There’s no way to
>> do it otherwise.

> Sure, because "have server setting blindly trump clients'" is *so* much
> better than "have client setting forwarded blindly to the server".
>
> And here I thought that, after OpenVPN painstakingly retrofitting one
> into their data channel setup, "when you need an agreement, you need an
> explicit negotiation phase" would be a commonly accepted tenet now ...

This would be a nice to have if it were possible.
But calling an impossible task "a commonly accepted tenet"
feels unwise to me.

> (As in, *let* the client send his settings, then have the shell's
> startup phase run a helper application that edits the env vars as
> necessary to achieve compatibility with the server's capabilities.)

And if the client says they want "zh_CN.UTF-16" but the server only
knowns how to do "C" and "en_US.UTF-8", then what are you going to do,
as just one example among a host of tricky combinations? In fact,
the only safe option in such a situation is to reject the connection.

And even if a safe setting existed in every case, which it does not,
it would be a complex and open-ended task to figure out what that setting
is on a given machine to be compatible with an arbitrary locale name
received over the wire, since POSIX explicitly says that the meaning
of locale names (apart from "C" and "POSIX") is implementation-defined.

So for every operating system and every possible subset of locales that
might be installed on a server, OpenSSH maintainers would have to maintain
a list of how to best match *any* valid locale from *any* other system to
one of the locales available on the server. Even in ideal circumstances,
that's a nightmarish task that can never be completed but is highly
error-prone. Even if somebody would be willing to do all that work,
having complex scripts or helper applications called at this stage would
cause a security concern by adding attack surface.

Besides, in this world, circumstances are rarely ideal. In theory,
the same locale name might even refer to different locales on different
systems. Maybe even in practice: for example, "C" used to refer to an
effectively ISO-Latin-1 locale on old releases of OpenBSD (it no longer
does). It's an ugly memory even though reasons existed to do that.
Users might even install their own, personal locale, so a locale string
might even indicate a locale that is non-standard even for the operating
system the client happens to be running...

Sure, any magic scheme you might devise to achieve the above would
likely work in many cases, so users would get trained into an utterly
unsafe attitude of "locales just work with SSH" and stop thinking
about it. If the beast would then suddenly bite, it would bite all
the deeper.


In conclusion, i think it is better to take a firm stand and say:

It is purely the responsibility of the user to make sure that
the server locale and the client locale are compatible *before
connecting*. Otherwise, all bets are off. Ideally, use UTF-8
on both sides *and* make sure your xterm(1) runs in UTF-8 mode.

Yours,
Ingo
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
>> (As in, *let* the client send his settings, then have the shell's
>> startup phase run a helper application that edits the env vars as
>> necessary to achieve compatibility with the server's capabilities.)

That sounds the most sane way to me.


> And if the client says they want "zh_CN.UTF-16" but the server only
> knowns how to do "C" and "en_US.UTF-8", then what are you going to do,
> as just one example among a host of tricky combinations? In fact,
> the only safe option in such a situation is to reject the connection.

Yeah, that might be one option.


> And even if a safe setting existed in every case, which it does not,
> it would be a complex and open-ended task to figure out what that
> setting
> is on a given machine to be compatible with an arbitrary locale name
> received over the wire, since POSIX explicitly says that the meaning
> of locale names (apart from "C" and "POSIX") is implementation-defined.

Possibly.
Still, a 99.99% working solution should be easy enough --
and if your policy is stricter, than rejecting incompatible connections
(if even falling back to "C" doesn't work??) is possible.


> So for every operating system and every possible subset of locales that
> might be installed on a server, OpenSSH maintainers would have to
> maintain

No.
Not the OpenSSH maintainers, but the packagers -
they know at least what their target machine understands.



> Sure, any magic scheme you might devise to achieve the above would
> likely work in many cases, so users would get trained into an utterly
> unsafe attitude of "locales just work with SSH" and stop thinking
> about it. If the beast would then suddenly bite, it would bite all
> the deeper.

That's as it is right now, anyway.
Such a script would get _better_ compatibility than now.


> In conclusion, i think it is better to take a firm stand and say:
>
> It is purely the responsibility of the user to make sure that
> the server locale and the client locale are compatible *before
> connecting*. Otherwise, all bets are off.

Well, how do I find out what's available without connecting?

If the server falls back to "C" (and tells me loudly upon connecting!!)
I at least have a chance to diagnose.


> Ideally, use UTF-8
> on both sides *and* make sure your xterm(1) runs in UTF-8 mode.

Yeah, that's the easy way.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
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)
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On Thu, 2022-04-28 at 20:29 -0400, Demi Marie Obenour wrote:
> > 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.

Maybe it's too late in the night and I just miss the obvious point,...

... but what exactly is the security problem here (if one sends
LC_*/LANG ... or with locales in general)?


With or with any locale/character encoding differences, the (possibly
evil) remote side can send any arbitrary bytes to the terminal.

But how could it use this to for code execution on the local machine?


The only attack vector I see would be:
A remote side tricking a user into believing that he left SSH (but is
still on the remote side)... and then tricking him into e.g. entering a
password. But that should be independent of the locale/character
encoding.


What should be the attack with e.g. LC_NUMERIC? A remote side tricking
a user into using 3,14 instead of 3.14 and that having some attacking
effect? But if the remote side can mess with the locale (on its own
side)... it can anyway already do it's attack there?

Similar, if a evil remote side could swap yesexpr and noexpr in
LC_MESSAGES?
So what?
Tricking a user in to rm -ri / and then using 'n' which would then mean
'y'?
If the remote side can do this, it can again just delete those (remote)
files?


Cheers,
Chris.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
Hi Christoph,

Christoph Anton Mitterer wrote on Fri, Apr 29, 2022 at 03:57:51AM +0200:

> Maybe it's too late in the night and I just miss the obvious point,...
>
> ... but what exactly is the security problem here (if one sends
> LC_*/LANG ... or with locales in general)?

I already posted a link to an essay explaining that in this very thread:

https://undeadly.org/cgi?action=article&sid=20160308204011

> With or with any locale/character encoding differences, the (possibly
> evil) remote side can send any arbitrary bytes to the terminal.

Even is the user on the client side trusts root on the server that the
program /bin/ls is not malicious but does what it is designed to do,
including proper output sanition, a locale mismatch may make it trivial
for unprivileged users on the server to mount attacks by simply placing
maliciously named files into the file system, such that, depending
on your terminal settings on the client, for example "ls /tmp/" might
result in remote code execution on the client. Mounting DOS attacks is
even easier and typically works out of the box with the default xterm(1)
configuration on most operating systems (not on OpenBSD any more, though).

> But how could it use this to for code execution on the local machine?

By the remote attacker sending whatever of

https://invisible-island.net/xterm/ctlseqs/ctlseqs.html

is most inconvenient for you, the user on the client?
Good luck making sure nothing from that next to interminable list is
inconvenient for you. Other terminals and terminal emulations may have
similar lists of in-band controls.

> The only attack vector I see would be:
> A remote side tricking a user into believing that he left SSH (but is
> still on the remote side)... and then tricking him into e.g. entering a
> password. But that should be independent of the locale/character
> encoding.

Well, attackers tend to be creative, so social engineering is certainly
one among the many options. Maybe change window titles and key
bindings from the remote side or remap some output characters?
There are certainly plenty of options to choose from.

> What should be the attack with e.g. LC_NUMERIC?

For an attacker, LC_CTYPE is probably the more rewarding target.
But if you type 42,95 EUR because you think you have a german
locale and that turns out to mean 4295 EUR because the server
actually uses a US locale (or something like that), i expect it
might have unfortunate consequences in some situations.

Besides, it is not just attacks that you should worry about,
but also accidental misbehaviour of application programs if the
locale used is not the one you think.

> A remote side tricking
> a user into using 3,14 instead of 3.14 and that having some attacking
> effect? But if the remote side can mess with the locale (on its own
> side)... it can anyway already do it's attack there?

One among the issues here is that if users get used to LC_* usually
being transparently passed along, misbehaviour may take them by
surprise when they stumble upon a server that simply doesn't have
their locale installed - even when the character encodings match
and even when there is no attackaer involved.

> Similar, if a evil remote side could swap yesexpr and noexpr in
> LC_MESSAGES?
> So what?

Again, no attacker needed to come to grief, it is trivial to imagine
all kinds of trouble. The user wants to delete a sensitive file because
it contains secret information, for example before making the directory
readable for other users. Since they have a german locale set on the the
client side, they type "ja" when the program on the server asks whether
they really want to delete the file. But the server does not have a
german locale installed, so "ja" actually means "no", the file remains,
and the secret information is accidentally disclosed without the poor
user even suspecting something might have gone wrong.

Note there are at least three very different levels of problems here,
but all of them are exacerbated by automatic passing of LC_* and
the implicit user expectations trained by that passing:

- Accidental misbehaviour, causing the user to not accomplish
what they think they accomplished, or receiving incorrect
answers to whatever questions they intended to ask.

- Attacks of unprivileged users on the server against terminal
security on the client, even when root on the server is
trustworthy and utility programs on the server do proper
sanitation before sending data over the wire.

- Attacks by malicious server administrators are probably the
least concern. Then again, if /etc/ssh/banner did remote
code execution on the client, i guess that *would* surprise
you, wouldn't it?

Yours,
Ingo
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
>> But how could it use this to for code execution on the local machine?
>
> By the remote attacker sending whatever of
>
> https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
>
> is most inconvenient for you, the user on the client?

Well, the only solution for that is to have a client that filters
the incoming control sequences (tmux was already mentioned?!).


Or use a remote terminal - like with mosh, which has a screen
on the remote side and only transfers the characters and colors -
so no local keyboard redefinitions, window title changes, etc.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
Hi,

Demi Marie Obenour wrote on Thu, Apr 28, 2022 at 08:29:24PM -0400:
> On 4/27/22 05:40, Ingo Schwarze wrote:
>> Demi Marie Obenour wrote on Tue, Apr 26, 2022 at 09:12:07PM -0400:
>>> On 4/25/22 08:23, Ingo Schwarze wrote:

>> In OpenBSD, we are used to the deliberate
>> decision that the C library ignores all aspects of the locale except
>> the character encoding, [...]

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

I think having libc and POSIX utility programs always reliably print
diagnostics in the same way, and always in US-ASCII rather than sometimes
in UTF-8, is more valuable than internationalization of operating
system diagnostics, both from the user perspective (predictability and
comprehensibility) and from the OS maintainer perspective (code simplicity
and hence better change for correctness and reliability). Even as a
native German speaker, i regularly get confused when seeing German
error messages because they usually feel quite incomprehensible.

Besides, LC_CTYPE is essential for important functionality, but picking
individual features from all the rest of LC_* for implementation isn't
going to help. It will increase code complexity without really
achieving internationalization (even full LC_* support is not really
sufficient for complete internationalization...). So better ditch
it outright than attempt some piece-meal approach.

Besides, even LC_MESSAGES has features that are prone to causing
trouble, for example changing the meaning of "yes" and "no".

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

Yes, because US-ASCII is a subset of UTF-8, so what a well-behaved
server sends in the C locale is supposed to be a subset of what it
might send in a UTF-8 locale.

Of course, whether it is safe when both the server and the client use
a UTF-8 locale obviously depends on the terminal or terminal emulator,
but at least xterm(1) in UTF-8 mode [.but not in the traditional 8-bit
mode that may still be the default on some operating systems] is safe
when the server runs either the C locale or a UTF-8 locale.

[...]
>> 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.

Frankly, i don't know anything about tmux(1) and simply don't know
whether it can or cannot help with the topic at hand.

> 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.

xterm(1) in UTF-8 mode is quite good because it never interprets
multibyte characters as in-band terminal control codes. Your
mileage might vary with other terminals or emulators.

Yours,
Ingo
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On Fri, 2022-04-29 at 12:53 +0200, Ingo Schwarze wrote:
> I already posted a link to an essay explaining that in this very
> thread:
>
>   https://undeadly.org/cgi?action=article&sid=20160308204011

Well I had read that but didn't understand the concrete attack from
it... other than garbling up the terminal.


> Even is the user on the client side trusts root on the server that
> the
> program /bin/ls is not malicious but does what it is designed to do,
> including proper output sanition, a locale mismatch may make it
> trivial
> for unprivileged users on the server to mount attacks by simply
> placing
> maliciously named files into the file system, such that, depending
> on your terminal settings on the client, for example "ls /tmp/" might
> result in remote code execution on the client.

On the client?! How would that work?

I mean that would either mean...

... that there needs to be some way via ssh itself, ... the only thing
I can think of is that via some tricky escape sequences ssh could be
tricked into believing ~C was pressed. But I'd hope that it only uses
the ssh client's stdin for that, which the remote shouldn't be able to
mess with?!

... or if the terminal would provide any escape sequences for local
code execution.
I couldn't find any such for xterm,... are there?

The worst thing I'm aware of are things (like OSC 52, see
e.g. https://gitlab.gnome.org/GNOME/vte/-/issues/2495#note_1176783 and
I'm still not 100% sure their safeguard is 100% save ) which would
allow an attacker to read/write to the clipboard.
Or perhaps things like creating clickable URLs in the terminal, which
the user might accidentally click on.


But for all these things I don't see the specific dependence on any
evil-local-games?

If the remote root (or hardware) is compromised, it can replace all
programs anyway, and send any terminal escape sequence via any (e.g.
ls) it likes.
Regardless of any locale settings.

If only the remote (non-root-)user was compromised, it could still do
so in many cases (by overwriting the remote PATH and have his forged
versions of standard tools being used). Similarly it could just set any
desired LC_*/LANG in .profile/etc.?
The only exception was if a command were directly executed by ssh on
the remote side... but IIRC, even if you do ssh example.org command, it
still runs the command via a shell (just not a login shell), so e.g.
.bashrc would still be executed and give a compromised remote user the
chance to do some evil.


> Mounting DOS attacks is
> even easier and typically works out of the box with the default
> xterm(1)
> configuration on most operating systems (not on OpenBSD any more,
> though).

Sure... but e.g. what you've described in the earlier link, didn't work
for me.
And if such DOS happens, then people simply close the terminal windows
and start a fresh one?

Or is there anything like terminal escape sequences being able to map
character key codes, e.g. that one types "en .ed &" but the terminal
sends "rm -rf /" to the process?


> > But how could it use this to for code execution on the local
> > machine?
>
> By the remote attacker sending whatever of
>
>   https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
>
> is most inconvenient for you, the user on the client?
> Good luck making sure nothing from that next to interminable list is
> inconvenient for you.  Other terminals and terminal emulations may
> have
> similar lists of in-band controls.

Any concrete example which allows *local* (i.e. client side) execution
of code/commands?

IMO any such would be grave security holes in the terminal, but still
rather unrelated to the locale.


And I'm not saying that the situation with terminals is good...
Take the aforementioned OSC52.
Or similarly OSC 7 (https://gitlab.freedesktop.org/terminal-
wg/specifications/-/issues/20#note_956242 ), which allows setting the
(local) current working directory and could IMO allow for subtle
attacks.

But I'm kinda missing the smoking gun, which allows the direct local
code execution you indicate.


> Well, attackers tend to be creative, so social engineering is
> certainly
> one among the many options.  Maybe change window titles and key
> bindings from the remote side or remap some output characters?

I'd say the changed window titles is kinda "expected"... I.e. no sane
person would assume that if the window title says "execute rm -rf / as
root now" this is some advise from the local system that one should do.

Are there really char remapping sequences? But these should still only
affect the terminal window in question, right? Not anything else.

These
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Mouse-Tracking
seem a bit concerning...


So perhaps the best would be if SSH had a mode where it filters any
terminal sequences that are not deemed generally safe.
Of course it would need to do so only when the output actually goes to
a terminal.


> For an attacker, LC_CTYPE is probably the more rewarding target.
> But if you type 42,95 EUR because you think you have a german
> locale and that turns out to mean 4295 EUR because the server
> actually uses a US locale (or something like that), i expect it
> might have unfortunate consequences in some situations.

Sure but if you trust the remote side to do any wire transfers for
you,... and remote is compromised, ... it doesn't need to play any
cumbersome locale games... it simply replaces the program, captures
your password/etc. (that you use to authorize the tranfer) and fills in
any number it wishes.


> Besides, it is not just attacks that you should worry about,
> but also accidental misbehaviour of application programs if the
> locale used is not the one you think.

I don't think these are the big problems. The reality is, that most
systems have the standard set of e.g. glibc locales installed, so even
if you send your LC_*/LANG to remote, you'll see there more or less the
same than what you have here (given the locales are enabled there - and
if not, you see errors right away).

Most people use nowadays UTF8 locales, so unless one uses some very
weird char encoding, that should be just fine too.


But again, even if there would be problems in that field... an attacker
could simply set another locale in the remote .bashrc/etc.?



> > A remote side tricking
> > a user into using 3,14 instead of 3.14 and that having some
> > attacking
> > effect? But if the remote side can mess with the locale (on its own
> > side)... it can anyway already do it's attack there?
>
> One among the issues here is that if users get used to LC_* usually
> being transparently passed along, misbehaviour may take them by
> surprise when they stumble upon a server that simply doesn't have
> their locale installed - even when the character encodings match
> and even when there is no attackaer involved.

Well and if they don't pass it on (and even if the remote side *would*
have their "native" local installed),.. they might be easily confused
by a huge number of remote systems and not knowing which of them uses
e.g. which decimal symbol.

So from that PoV it would IMO actually make more sense to *do* send
these env vars so that it's likely that the user get's the same
behaviour is is expecting locally.
And again, if the remote side was evil in that case... it could be so
with or without any variable passing.


> Again, no attacker needed to come to grief, it is trivial to imagine
> all kinds of trouble.  The user wants to delete a sensitive file
> because
> it contains secret information, for example before making the
> directory
> readable for other users.  Since they have a german locale set on the
> the
> client side, they type "ja" when the program on the server asks
> whether
> they really want to delete the file.  But the server does not have a
> german locale installed, so "ja" actually means "no", the file
> remains,
> and the secret information is accidentally disclosed without the poor
> user even suspecting something might have gone wrong.

Sure... but even I wouldn't call this a real attack vector (and I call
things like the remote side being able to just *set* (not even read) my
clipboard a possible attack vector).

Similar issues can happen with or without any local games...you just
need different versions of tools, and some option wasn't supported yet.

So at best this seems like cases of accidents, but none which are
really restricted to consequences of non-matching locales. I guess
these kinds of problems are simply expected.


>  - Accidental misbehaviour, causing the user to not accomplish
>    what they think they accomplished, or receiving incorrect
>    answers to whatever questions they intended to ask.

I wouldn't call these attacks... either they're because of non-matching
locales or different software version and the like, and that's simply
something one needs to expect when one goes on a remote system.
Just as I cannot expect the remote system to be Debian and have e.g.
aptitude installed.


>  - Attacks of unprivileged users on the server against terminal
>    security on the client, even when root on the server is
>    trustworthy and utility programs on the server do proper
>    sanitation before sending data over the wire.
>
>  - Attacks by malicious server administrators are probably the
>    least concern.  Then again, if /etc/ssh/banner did remote
>    code execution on the client, i guess that *would* surprise
>    you, wouldn't it?

I am in fact concerned about terminal implementers adding more and more
features that might at least subtly be abused... and these typically
seem to be even always-on and not opt-in.


But I still haven't seen a concrete remote code execution example here.
Changing the window title barely isn't an attack.



Cheers,
Chris.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On 4/29/22 07:29, Ingo Schwarze wrote:
> Hi,
>
> Demi Marie Obenour wrote on Thu, Apr 28, 2022 at 08:29:24PM -0400:
>> On 4/27/22 05:40, Ingo Schwarze wrote:
>>> Demi Marie Obenour wrote on Tue, Apr 26, 2022 at 09:12:07PM -0400:
>>>> On 4/25/22 08:23, Ingo Schwarze wrote:
>
>>> In OpenBSD, we are used to the deliberate
>>> decision that the C library ignores all aspects of the locale except
>>> the character encoding, [...]
>
>> Off-topic: Why did OpenBSD make this decision? In particular,
>> LC_MESSAGES seems to be essential to internationalization support,
>> without being very problematic otherwise.
>
> I think having libc and POSIX utility programs always reliably print
> diagnostics in the same way, and always in US-ASCII rather than sometimes
> in UTF-8, is more valuable than internationalization of operating
> system diagnostics, both from the user perspective (predictability and
> comprehensibility) and from the OS maintainer perspective (code simplicity
> and hence better change for correctness and reliability). Even as a
> native German speaker, i regularly get confused when seeing German
> error messages because they usually feel quite incomprehensible.
>
> Besides, LC_CTYPE is essential for important functionality, but picking
> individual features from all the rest of LC_* for implementation isn't
> going to help. It will increase code complexity without really
> achieving internationalization (even full LC_* support is not really
> sufficient for complete internationalization...). So better ditch
> it outright than attempt some piece-meal approach.
>
> Besides, even LC_MESSAGES has features that are prone to causing
> trouble, for example changing the meaning of "yes" and "no".
>
>> Also, is it safe if the server uses the C locale (LC_ALL=C) and the
>> client uses UTF-8?
>
> Yes, because US-ASCII is a subset of UTF-8, so what a well-behaved
> server sends in the C locale is supposed to be a subset of what it
> might send in a UTF-8 locale.
>
> Of course, whether it is safe when both the server and the client use
> a UTF-8 locale obviously depends on the terminal or terminal emulator,
> but at least xterm(1) in UTF-8 mode [.but not in the traditional 8-bit
> mode that may still be the default on some operating systems] is safe
> when the server runs either the C locale or a UTF-8 locale.
>
> [...]
>>> 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.
>
> Frankly, i don't know anything about tmux(1) and simply don't know
> whether it can or cannot help with the topic at hand.

Generally speaking, a server one connects to via SSH is *not* assumed
to be trusted. Therefore, if the server can compromise the client,
that is a security vulnerability in the client. The only remaining
problem is client-side state being messed up, and the easiest solution
to that is to destroy the PTY once the session is complete.

--
Sincerely,
Demi Marie Obenour (she/her/hers)
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On 28.04.22 11:05, Ingo Schwarze wrote:
> Jochen Bern wrote on Thu, Apr 28, 2022 at 08:53:32AM +0200:
>> And here I thought that, after OpenVPN painstakingly retrofitting one
>> into their data channel setup, "when you need an agreement, you need an
>> explicit negotiation phase" would be a commonly accepted tenet now ...
>
> This would be a nice to have if it were possible.
> But calling an impossible task "a commonly accepted tenet"
> feels unwise to me.

It was not "impossible" for the developers of OpenVPN, and those did
*not* have the advantage of one side *already* havind a mechanism to
pass the pertinent information to the other, like OpenSSH does with the
env var forwarding for the (client side) locales.

> And if the client says they want "zh_CN.UTF-16" but the server only
> knowns how to do "C" and "en_US.UTF-8", then what are you going to do,
> as just one example among a host of tricky combinations? In fact,
> the only safe option in such a situation is to reject the connection.

If that's your opinion, go ahead and implement it. Which my suggestion
of a server-side helper evaluating the client-side-set and
server-side-available locales for *some* decision *does* support. It
actually even allows you to send back a US-ASCII error message *telling*
the user what the problem is before summarily kicking him out. But don't
expect the rest of the planet to join you in waiting for the *perfect*,
totally loophole-free solution you seem to insist on.

Which is not to say, mind, that such a thing will not come EVENTUALLY.
Unicode seems well-poised to prove being the end-all complete framework
for transmitting and outputting texts, short of quipus or a first
contact situation; I expect terminals to gravitate more and more towards
implementing it, increasing the pressure on the consortium to include
two codepoints to "shift to control" and "shift back" into its
standards, laying the groundwork of a *global* algorithm for terminals
to tell control data from content.

(And considering that easily more than half of the control sequences
*do* have an effect on the rendering of the "printable" text, who says
that standardizing them in their entirety is forever outside the
consortium's purview, even?)

But no guarantees that any of that is going to come full circle within
any present company's lifetimes, though. Hence the question what *we*
can do to improve the situation, if only partially.

> And even if a safe setting existed in every case, which it does not,
> it would be a complex and open-ended task to figure out what that setting
> is on a given machine to be compatible with an arbitrary locale name
> received over the wire, since POSIX explicitly says that the meaning
> of locale names (apart from "C" and "POSIX") is implementation-defined.

That situation is, however, not going to improve if you go and tell
everyone that "it's nobody else's business" if they choose to keep
inventing their very own locale XY_äöü for language XY. And the way it
is right now, chances are that such maintainers will *never even hear*
about the interoperability problems they cause. Even if an interop
standards project (like one to write said helper) cannot *solve*
everything, it can at least *demonstrate* that XY_äöü causes
significantly more problems that XY_ok, and *why* that is.

> So for every operating system and every possible subset of locales that
> might be installed on a server, OpenSSH maintainers would have to maintain

... absolutely nothing. SSH is merely the means connecting a terminal
(some device to present "printable" data) to a - likely remote -
shell/application (producing such data), and can be replaced by pretty
much everything from ye olde serial cable to whatever post-quantum
communications protocol minimizes in-transit bit decay by Dark Energy.
All that is required from OpenSSH is to transport the information "this
is a remote connection" and "these are the other side's capabilities",
and setting the SSH_* and LC_* env vars on the server side already does
that nicely.

I'm using the term "(external) helper" instead of "code (to be
integrated into OpenSSH)" for a *reason*, you know.

> Users might even install their own, personal locale, so a locale string
> might even indicate a locale that is non-standard even for the operating
> system the client happens to be running...

Well, breaking interoperability between "themselves" (user and their DIY
software) and their *own* computer should teach them to be wary of
distribs that do not bother about cross-platform interop *real* fast ...

... hmmm, I wonder, would they actually be able to vote with their feet
and install a port of a better-interop locale from another distrib over
an isolationist one that came with their locally installed distrib ... ?

> Since they have a german locale set on the the
> client side, they type "ja" when the program on the server asks whether
> they really want to delete the file. But the server does not have a
> german locale installed, so "ja" actually means "no", the file remains,
> and the secret information is accidentally disclosed without the poor
> user even suspecting something might have gone wrong.

Fine, let's assume for a moment that being prompted with

> Effacer le fichier ULTRAGEHEIM.txt? [o/N] _
fails to inform the user that the server is not exactly talking German
to him. Let's further assume that we're not talking about a yes/no
decision (FYI, I would still have to find a German localization asking
"j/N ?" that would not also accept the C/English "y" for a "yes"), but
something that's not as trivial to translate - say, the user enters an
amount thinking of € but the software takes it as ¥.

Now how is *that* an argument in *favor* of your proposal of having the
server *downright ignore* the locale the user has tried to set!? A user
*that* dependent on a never-changing interface, and robbed of the option
of adapting the server's setup, would need to have a dedicated immutable
server to use for the rest of his (work)life. (Preferably one that still
accepts amounts in DM instead of €, I suppose.)

Regards,
--
Jochen Bern
Systemingenieur

Binect GmbH
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On Sun, 1 May 2022, Jochen Bern wrote:

> If that's your opinion, go ahead and implement it. Which my suggestion of a
> server-side helper evaluating the client-side-set and server-side-available
> locales

This could be… challenging. (There’s locale(1) -a, sure, but…)

It also assumes locale support on both ends in the first place.

> situation; I expect terminals to gravitate more and more towards implementing
> it, increasing the pressure on the consortium to include two codepoints to
> "shift to control" and "shift back" into its standards, laying the groundwork
> of a *global* algorithm for terminals to tell control data from content.

I highly doubt anything will change now, especially things that break
compatibility.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

****************************************************
/?\ The UTF-8 Ribbon
? ? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
 ?  HTML eMail! Also, https://www.tarent.de/newsletter
? ? header encryption!
****************************************************
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

1 2  View All