2015-06-30 13:30:50 +0200, Vincent Lefevre:
[...]
I don't understand what you mean.
My point was, applications/systems use different locales. Nothing will
change that.
Thus when you process output from a remote application on the local
system, you must assume that this is happening or
On 2015-06-30 16:09:29 +0100, Stephane Chazelas wrote:
2015-06-30 16:45:59 +0200, Vincent Lefevre:
On 2015-06-30 15:04:17 +0100, Stephane Chazelas wrote:
From a UTF-8 terminal:
luit -encoding 'ISO 8859-1' ssh host-known-to-use-latin1
This is not very good, because the default
2015-06-30 15:04:17 +0100, Stephane Chazelas:
[...]
ssh -t host luit
(assuming luit is installed on host).
(unfortunately it doesn't seem to support the /new/ Western
Europe charset iso8859-15).
[...]
Sorry, it does support it, but it seems it fails to detect it
properly from the locale:
On 2015-06-30 15:04:17 +0100, Stephane Chazelas wrote:
Or use luit that has been designed for that:
However it doesn't work from non-UTF-8 terminals.
From a UTF-8 terminal:
luit -encoding 'ISO 8859-1' ssh host-known-to-use-latin1
This is not very good, because the default encoding on the
On Tue, 2015-06-30 at 17:26 +0200, Vincent Lefevre wrote:
Sending TERM is absolutely necessary because different terminals
behave in different ways.
And that's why SSH sends it... others are not important, thus, they
don't sent by default.
What keeps you from also just setting your LC_*,
On Tue, 2015-06-30 at 13:30 +0200, Vincent Lefevre wrote:
You should learn how terminals work. When using a terminal, the
remote
charmap MUST be the same as the local one (or be a subset), otherwise
the terminal cannot interpret the byte sequences correctly.
Sure... I haven't said that I
2015-06-30 16:45:59 +0200, Vincent Lefevre:
On 2015-06-30 15:04:17 +0100, Stephane Chazelas wrote:
Or use luit that has been designed for that:
However it doesn't work from non-UTF-8 terminals.
Yes, though if you don't use a UTF-8 terminal you won't be able
to see arbitrary characters from
On Tue, 2015-06-30 at 17:36 +0200, Vincent Lefevre wrote:
how to use GNU screen without writing it
explicitly?
For instance:
ssh host my_command
where my_command is automatically run under GNU screen.
When you invoke ssh like this, it executes the command with SHELL -c
mycommand,
On 2015-06-30 16:32:53 +0200, Christoph Anton Mitterer wrote:
On Tue, 2015-06-30 at 13:30 +0200, Vincent Lefevre wrote:
This is not completely true: this is the case *by default*, but the
user can always change the default. When I get an account on a
machine,
one of the first things I do
On 2015-06-30 05:35:16 +0200, Christoph Anton Mitterer wrote:
On Tue, 2015-06-30 at 04:30 +0200, Vincent Lefevre wrote:
Well but there one knows / must assume at least that this can
happen:
When one remotely accesses a system and processes output from
there, it
must be assumed
On 2015-06-29 05:43:07 +0200, Christoph Anton Mitterer wrote:
We've had the same discussion last time when it was about LC_*.
It's generally a bad idea to change the secure default of not
forwarding/accepting anything.
I completely disagree that passing XTERM_VERSION is not secure
(this RFE
Hey
Am 29. Juni 2015 14:25:15 MESZ, schrieb Vincent Lefevre
vinc...@vinc17.net:
I completely disagree that passing XTERM_VERSION is not secure
(this RFE is about this particular variable, and not anything else).
To be honest, I think it's at best naive to assume, that one can
predict whether
On Mon, 2015-06-29 at 20:55 +0100, Stephane Chazelas wrote:
$TERM is already passed but only when a pty is requested.
Which is by far not the only use case of ssh.
Actually there are many major use cases where no pty is involved at all
(and where ssh serves just as a crypto transport layer), but
On 2015-06-29 22:50:59 +0200, Christoph Anton Mitterer wrote:
On Mon, 2015-06-29 at 20:55 +0100, Stephane Chazelas wrote:
Note that LANG/LC_* which Debian ssh already accepts is probably one
of the worst one as it affects so many commands. That also
affects bash shell grammar parsing which
On 2015-06-30 02:53:23 +0200, Christoph Anton Mitterer wrote:
On Tue, 2015-06-30 at 01:23 +0200, Vincent Lefevre wrote:
On the other hand, having the wrong charmap on the other side is a
security issue, because remote utilities could send characters that
they think to be printable, but are
On Tue, 2015-06-30 at 04:30 +0200, Vincent Lefevre wrote:
Well but there one knows / must assume at least that this can
happen:
When one remotely accesses a system and processes output from
there, it
must be assumed that there are different locales/etc. and
appropriate
means taken.
On Tue, 2015-06-30 at 01:23 +0200, Vincent Lefevre wrote:
On the other hand, having the wrong charmap on the other side is a
security issue, because remote utilities could send characters that
they think to be printable, but are actually control characters /
escape sequences due to the wrong
Source: openssh
Version: 1:6.7p1-6
Severity: wishlist
Passing the terminal version to the server side is useful for programs
that depend on some terminal features (for instance, to make sure that
some query escape sequence will receive an answer).
In the case of xterm, it is provided by
We've had the same discussion last time when it was about LC_*.
It's generally a bad idea to change the secure default of not
forwarding/accepting anything.
Due to past errors, we're already in the unfortunate situation that
this is done for an arbitrary number of vars, and regrettably the
19 matches
Mail list logo
