Whonix identifies locale configuration issue causing SSH special character rendering errors

Whonix developers have identified a technical issue where SSH-based tools fail to render special characters correctly within the Whonix environment. Users reported that terminal applications, such as tmux, would not display non-standard characters unless specific flags like '-u' were manually applied.

The root cause has been traced to the desktop configuration scripts, specifically within the LXQt session startup process. The investigation revealed that the LC_ALL environment variable is being hardcoded to the 'C' locale without preserving the user's original settings, which directly impacts how terminal emulators and SSH tools interpret character encoding.

Technical cause and planned resolution

• Locale Misconfiguration: The variable LC_ALL is being explicitly set to 'C' within /usr/libexec/desktop-config-dist/start-lxqt-session, preventing the use of UTF-8 or other extended character sets.
• UWT Wrapper Impact: The uwt (Universal Terminal Wrapper) tool requires internal adjustments to ensure that while it may use LC_ALL=C for internal operations, it does not force this restrictive locale onto the launched programs.
• Affected Components: The issue has been reproduced on both Whonix-Gateway and Whonix-Workstation running on VirtualBox using Debian Trixie-based repositories.
• Release Timeline: A fix is not expected in the upcoming Whonix 18.2.4.3 release; instead, it is slated for Whonix 18.2.4.4, which will undergo extensive testing due to concurrent complex system improvements.

Why it matters

This fix is critical for Whonix users who rely on secure, remote terminal sessions for administration, as improper character rendering can lead to user error or misinterpretation of command outputs. For developers of privacy-focused distributions, it highlights the importance of careful locale management in desktop session scripts to maintain compatibility with modern terminal tools.