2015-06-29 18:55:52 +0200, Christoph Anton Mitterer: [...] > Sending XTERM_VERSION would be surely not enough, one would at least > need TERM as well, I'd guess. [...]
$TERM is already passed but only when a pty is requested. It should be the same for $XTERM_VERSION or any other variable that further qualify any terminal identity if ever you decided to pass them 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 was why CVE-2014-0475 could be exploited over ssh for instance to run arbitrary commands on git servers. XTERM_VERSION seems to be a lot less likely to do harm, but as you say if we start passing one variable by one particular terminal emulator, we may end up having to do the same for dozens other applications. For $XTERM_VERSION, it's not even needed as there are other ways to get the xterm version. TZ is another one that would make sense to pass across but it's even more dangerous than LC_*. What would be useful however IMO, would be to have a dedicated harmless env var namespace passed accross consistently in all ssh deployments (like SSHENV_*) so we can reliably pass information from the client to the remote command. like: At the moment, one can hijack LC_* on many ssh deployments for that but that's just a dirty hack. See http://unix.stackexchange.com/questions/205567/how-to-execute-an-arbitrary-simple-command-over-ssh-without-knowing-the-login-sh for what I mean. It would probably make sense to be more restrictive when there's a ForceCommand than when there's none and the login shell of the remote user is not restricted (lets you set env vars anyway). -- Stephane -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
