Red Hat Bugzilla – Full Text Bug Listing
|Summary:||ssh/sshd doesn't send/accept LANGUAGE environment variable, which causes unexpected behaviour|
|Product:||[Fedora] Fedora||Reporter:||Jarkko <jval>|
|Component:||openssh||Assignee:||Tomas Mraz <tmraz>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||5.0p1-3.fc9||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-06-11 00:36:19 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Jarkko 2008-04-19 10:01:28 EDT
Description of problem: I have LANG set to fi_FI.UTF-8, but I configured gettext to use English, so I have LANGUAGE set to: en_GB.UTF-8:en_US.UTF-8:en.UTF-8 Version-Release number of selected component (if applicable): At least openssh-4.7p1-4.fc8 and older (very probably also latest in rawhide) Actual results: Because LANGUAGE isn't passed, I suddenly start to get Finnish messages on the remote server. Expected results: English messages also on the remote server, because LANGUAGE is set to en. Additional info: Add "SendEnv LANGUAGE" to /etc/ssh/ssh_config and "AcceptEnv LANGUAGE" to /etc/ssh/sshd_config and this is fixed. I know LC_MESSAGES would be passed, but in my case I can't use LC_MESSAGES... Anyhow, not passing LANGUAGE is inconsistent behaviour when LANG and LC_MESSAGES are passed (if we pass language related variables, we really should pass them all). If those ssh_config and sshd_config files are from upstream, please report this to upstream. Thanks.
Comment 1 Jarkko 2008-04-29 05:27:55 EDT
Another issue (but I'll comment here because it's related to this issue): $ env | grep LANG LANG=en_GB.UTF-8 GDM_LANG=en_GB.UTF-8 $ env | grep LC LC_PAPER=fi_FI.UTF-8 LC_ADDRESS=fi_FI.UTF-8 LC_MONETARY=fi_FI.UTF-8 LC_NUMERIC=fi_FI.UTF-8 LC_TELEPHONE=fi_FI.UTF-8 LC_COLLATE=fi_FI.UTF-8 LC_IDENTIFICATION=fi_FI.UTF-8 LC_MEASUREMENT=fi_FI.UTF-8 LC_CTYPE=fi_FI.UTF-8 LC_NAME=fi_FI.UTF-8 Then, I connect with ssh to a server running Debian etch (latest stable): $ env | grep LANG LANG=en_US.ISO-8859-15 LANGUAGE=en_FI:en_US:en_GB:en $ env | grep LC LC_PAPER=fi_FI.UTF-8 LC_ADDRESS=fi_FI.UTF-8 LC_MONETARY=fi_FI.UTF-8 LC_NUMERIC=fi_FI.UTF-8 LC_TELEPHONE=fi_FI.UTF-8 LC_IDENTIFICATION=fi_FI.UTF-8 LC_COLLATE=fi_FI.UTF-8 LC_MEASUREMENT=fi_FI.UTF-8 LC_CTYPE=fi_FI.UTF-8 LC_NAME=fi_FI.UTF-8 This causes: $ locale LANG=en_US.ISO-8859-15 LANGUAGE=en_FI:en_US:en_GB:en LC_CTYPE=fi_FI.UTF-8 LC_NUMERIC=fi_FI.UTF-8 LC_TIME="en_US.ISO-8859-15" LC_COLLATE=fi_FI.UTF-8 LC_MONETARY=fi_FI.UTF-8 LC_MESSAGES="en_US.ISO-8859-15" LC_PAPER=fi_FI.UTF-8 LC_NAME=fi_FI.UTF-8 LC_ADDRESS=fi_FI.UTF-8 LC_TELEPHONE=fi_FI.UTF-8 LC_MEASUREMENT=fi_FI.UTF-8 LC_IDENTIFICATION=fi_FI.UTF-8 LC_ALL= This happens because we send and the server accepts. :) I know this can be thought as a bug on the server side shell profile scripts (because it should either use the settings from the client or from the server - not to mix them), but this is the real world. This is happening now with almost all servers... I've already sent patches to Fedora's initscripts maintainer about handling this properly in Fedora, but we can't fix all the distros out there... :) Of course if the client only defines LANG, things will work properly. But that can't be the "solution" to this problem. The LC_* variables are here to stay and they should be handled properly. Because of this, I wonder if it's a good choise to set the system to send the locale related variables to the remote server by default. It might be a better solution to disable sending them by default and add e.g. a host specific example to the ssh_config file so that the administrator can define host specific SendEnvs when needed. I'm not sure which is better, but I wanted to bring this to your attention so that you can decide how it is handled best. The problem with mixing these variables is that when mixing different encodings, weird things start to happen. Without the encoding issue, this would not be a real world problem.
Comment 2 Jarkko 2008-04-29 12:47:03 EDT
Actually passing locale settings is a really good thing after all! I can see this especially when using a real terminal. Without passing the encoding information, the terminal doesn't work properly. Of course the server side needs to have the passed locale installed and there are perhaps issues when only some of the LC_* variables are sent, but in general it's still much better to send the locale settings than not to send them. (Because the client always "talks" to the server in its own encoding by default.) So I'd just ignore the thought that sometimes this causes problems (especially when the server overrides the sent settings). We don't live in a perfect world. In this case sending the locale settings by default in ssh_config is the better compromise than not to send them. :) I noticed that sometimes variables LESSCHARSET and LESSCHARDEF are also used (usually unnecessarily, but hey... sometimes the server administrators set them "just in case" - which then causes problems when the encodings differ between the client and the server...). Perhaps those should also be sent and accepted by ssh_config and sshd_config. They are character set related, and therefore locale related - like the LANGUAGE variable is language related (and therefore locale related). I think all character set and language related variables should be sent and accepted to prevent these encoding and language setting mix situations. Perhaps the configuration should be like this (* character can be used, so there's actually no need to list them all explicitly): ssh_config: SendEnv LANG LC_* LANGUAGE LESSCHAR* sshd_config: AcceptEnv LANG LC_* LANGUAGE LESSCHAR*
Comment 3 Jarkko 2008-04-29 16:08:51 EDT
LESSCHAR* are apparently old variables (coming from the days when less didn't support the locale system). As the servers out there in the real world don't have them in AcceptEnv at the moment, it's more like a cosmetic thing if they are added. Perhaps they should be added, but that doesn't matter much in real life, so I don't mind if it's decided that they are not added. (One reason not to add them might be that we perhaps don't want to support using these old and unnecessary variables used by only one software... :)) Then there is also that locale and language related environment variable LINGUAS. I'd say it's more related to the configuration on the actual host being used though, so I'd not add that to the list of passed variables. It would cause gray hair and a behavior which would just surprise the users in a bad way. :) LANGUAGE is a different variable in its purpose. It's clearly related to the locale configuration as it controls the same thing as LC_MESSAGES and LANG (the language of the messages). Therefore I think LANGUAGE should be passed perhaps. Or... Is LANGUAGE considered as a _local_ override for LC_MESSAGES? Have I understood its purpose the wrong way? If it's considered as a local override, this bug can be closed with NOTABUG or course. It's just that when LANG is passed and used, that already contains the language information - as does LC_MESSAGES... Therefore it all comes to this question: Is LANGUAGE a local override or just a list of preferred languages which should be used always and everywhere? Is it a preference list for the local system or for all systems in the user's session? I've thought it's a list for the whole session for the user, but I'm not 100 % sure anymore. It depends on how it's usually used - for what purpose. I'm trying to search the web about the real and intended official purpose of the LANGUAGE variable... Well one thing I found is the gettext documentation saying this: "you still need to have LANG (or LC_ALL) set to the primary language". So my bug report is invalid in its example. :D I'm not supposed to set LANG/LC_MESSAGES/LC_ALL and the first occurrence in LANGUAGE to different values - which I did. http://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html Based on the gettext documentation, LANGUAGE is not meant to be used as an override for the primary language. It seems to be more like a preference list to support also secondary language selection - not an overriding totally different value for LANG or LC_MESSAGES. So... If it's not used as a local override, I think it's then logical to pass it between systems when using ssh. It could be helpful and logical if the list is passed to the remote end also (user hopes to use e.g. sv:de:en - remote doesn't have sv, but has de --> user gets what she wants --> without passing LANGUAGE user would get the remote end's primary language which can be something totally different). The LESSCHAR* is not really needed and perhaps it's better not to support variables which are used only by one software. I know LANGUAGE is also for "one software" (gettext), but gettext is used by many programs and is a low level thing. So it's still different than the LESSCHAR* case. --> Okay... So although the "unexpected behaviour" is a bit exaggerated, I still think adding LANGUAGE is a good idea. I would not add LESSCHAR* after all (I changed my mind), so my original request about adding LANGUAGE is valid - and I think we only need to add LANGUAGE after all. And LANGUAGE can be overridden on the remote end in ~/.18n, /etc/profile or .bash_profile etc. anyway, so passing it through ssh does not take away the option of doing local overrides with it. Therefore I think adding LANGUAGE only brings more to the table. It should be added. It's clearly related to LC_MESSAGES and LANG. It's language related --> locale related. And we already pass locale variables. --> We should pass LANGUAGE also. So this is my request - as originally (although this is not about primary language like I thought, but supporting the preference list feels like the logical thing to do anyway - especially because supporting it doesn't take away anything, but adds support for reading the language preference list from the client side): One new line to ssh_config: SendEnv LANGUAGE One new line to sshd_config: AcceptEnv LANGUAGE My opinion is that adding LANGUAGE is the right thing to do. When passing language already in LANG, LC_MESSAGES and LC_ALL, it its the most logical thing to do to pass also LANGUAGE. This is what the user expects to happen. PS. Sorry for the long comment. This stuff is hard to figure out because it's different to configure your own system then to think about what kind of default configuration should be shipped with the package. In this case I think LANGUAGE should be there by default. That is the most logical way because I don't see it as a local-only variable. If the upstream ships this kind of configuration, they should be notified to add LANGUAGE also. I guess thought that they don't they being famous of shipping everything disabled by default. :)
Comment 4 Tomas Mraz 2008-04-29 16:33:55 EDT
Upstream doesn't enable anything like this. I think that we can add SendEnv/AcceptEnv LANGUAGE to rawhide.
Comment 5 Bug Zapper 2008-05-14 05:44:08 EDT
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Fedora Update System 2008-05-21 05:16:13 EDT
openssh-5.0p1-3.fc9 has been submitted as an update for Fedora 9
Comment 7 Fedora Update System 2008-05-22 16:37:42 EDT
openssh-5.0p1-3.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update openssh'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-4356
Comment 8 Fedora Update System 2008-06-11 00:36:15 EDT
openssh-5.0p1-3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.