Bug#790401: openssh: Please pass the XTERM_VERSION environment variable
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 that there are different locales/etc. and
> > > appropriate
> > > means taken.
> >
> > This is not possible. Or this would mean that the remote programs
> > can only output US-ASCII (which is compatible with everything).
>
> 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 assure that the
> expected locale is going to be set remotely as well.
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.
So, if there is no way to tell the remote side what the local charmap
is, then the only possibility is that the remote side uses a charmap
compatible with every other charmap, i.e. US-ASCII.
> > > Most systems likely either use C or UTF-8, and I'd be tempted to
> > > say
> > > it's a their problem if they use some obscure charmap.
> >
> > Well, ISO-8859-1 is not an obscure charmap and still exists in
> > Debian.
>
> Is there a strong reason to use it instead of UTF-8? (of course this
> alone doesn't fix your problem :) ).
If there is no reason to use ISO-8859-1, then why hasn't it been
removed from Debian (and other OS)? This would make things much
simpler (software testing, etc.).
> Plus there is no real guarantee that by accepting something like TERM,
FYI, again, TERM transmission is part of SSH, and this is AFAIK not
configurable: it is transmitted to the other side.
> LC_*, etc. at the server side even guarantees that the client get's
> what it likes.
That's true, and that's why the user needs to fix things by rc files
on the other side. And that's why some non-standard env variable is
needed to transmit the charmap (I use LC_CHARMAP), because the standard
LC_* variables do not (always) contain this information. Still, the
only way to get such information is to transmit it to the remote side,
and SSH developers decided that SendEnv/AcceptEnv was the way to do
(except for TERM, which is always transmitted when a pty is requested,
i.e. when it makes sense).
> For TERM this is most obvious: The terminfo files on the remote side
> may have a different version as locally, so even when one transmits it
> per default it still make be wrong in the end.
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 is to install terminfo files in my home
directory, so then I always have the same ones on all machines.
> Again take TERM... many other terminal emulators != xterm (or is it
> just GNOME? ;) ) still set it to "xterm", thereby breaking the whole
> idea of TERM.
Such terminal emulators are broken, and I don't use them, unless the
user can choose the value of TERM (remember that the user can also
install terminfo files is his home directory).
FYI, this is precisely because of this brokenness that Emacs uses a
timeout for its terminal queries (when TERM is xterm*), so that it
cannot be blocked when the real terminal does not recognize the usual
xterm queries. This timeout leads to corrupt files when the network
has important latency (which happens from time to time), because
the answer to the query (which looks like characters entered by the
user) is written to the file; and a way to avoid the timeout without
the risk of blocking Emacs would be to be able to get more information
via the environment, e.g. XTERM_VERSION.
Note that there is no such brokenness against VTE, so that VTE_*
variables would not be needed.
> > > > I wish SSH could pass the charmap
> > > Wouldn't that basically end up in the same concerns?
> >
> > In what way?
>
> Doesn't it also potentially affect the output/behaviour of programs?
It allows to get the same output as characters. For instance, if
the charmap is passed correctly, "env LANG=fr_FR cp" will always
output something like:
cp: opérande de fichier manquant
Saisissez « cp --help » pour plus d'informations.
Otherwise one can get garbage in the terminal.
> > Anyway, the upstream recommendation is to use AcceptEnv, which is
> > precisely what Debian is doing.
>
> With one tiny but important difference:
> upstream doesn't set a default and is strongly against having a default
> that would send/accept variables.
I don't care what upstream does. With Debian, the default is not
to have restricted user environments: when SSH is installed, any
local end user can log in via SSH. So, it makes sense to have a
default AcceptEnv following this.
> > I don't see why. Why would some program accidentally use SSHENV_FOO
> > but could not accidentally use SSH_ORIGINAL_COMMAND?
>
> Some days ago, a package like "thefuck" or so was added to the NEW
> queue, along with a discussion about whether that name is acceptable
> for Debian.
> This in turn reminded me about the "Lumia" which is former Nokia's
> smartphone but also (IIRC) a Spanish slang word for "prostitute" or
> something like that.
>
> In other words, what may seem obvious (i.e. that an env var of a
> certain name "belongs" to a certain sytem) to you and me, may be not to
> someone else.
In any case, if you think that there is any risk with SSHENV_FOO,
then there is also a risk for SSH_ORIGINAL_COMMAND.
Anyway, if some program wants to use SSHENV_FOO or SSH_ORIGINAL_COMMAND
for its own use, it should unset it first. This is good programming
practice.
> But SSH_ORIGINAL_COMMAND is at least not generally set, but rather only
> when command="command" and I think ForceCommand are used, which both
> again, isn't the case per default.
But if one doesn't use them, then the user can run any command by
default, and in particular, change the environment and do much more
things.
> > Similarly, the special shell could delete most of the environment
> > when starting.
>
> This would be a bad design paradigm.
Wrong.
> > BTW, a ssh server can have several users, with different needs:
> > some will need some environment variable passing, others won't
> > need that and can always clean up the environment before doing
> > anything else (say, start with "env -i" or do something similar).
>
> Which can be easily facilitated by a number of technologies in OpenSSH:
> - environment="NAME=value" in authorized_keys
> - PermitUserEnvironment in sshd_config
> (notice again, that the default to this directive is of course "no"
> for security reasons - just as with Send/AcceptEnv)
> - Match/Host blocks that select config directive based on the User/Host
> in ssh[d]_config
???
> > Note: I'm not sure whether the /etc/ssh/ssh_config SendEnv settings
> > can be overridden. If this is not possible, then the SendEnv
> > directive
> > should be removed from this file. This is not a problem for the user,
> > who can add SendEnv directives in his .ssh/config file if he wishes
> > to pass environment variables.
>
> In ssh usually (there are some strange special cases where this
> behaviour is a little bit altered) the first occurrence of a directive
> defines the value with later ones being ignored.
> So it can be overwritten.
But SendEnv is an exception:
Multiple environment variables may be separated by whitespace or
spread across multiple SendEnv directives.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
i.e. it seems that a SendEnv directive is not overwritten.
However I could check that the SendEnv line in /etc/ssh/ssh_config
only applies to Host *, not to specific host in the user's .ssh/config
file.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply to: