Bug 2352653
| Summary: | RFE: Consider sending COLORTERM= via SendEnv by default | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Lennart Poettering <mzeuom> |
| Component: | openssh | Assignee: | Dmitry Belyavskiy <dbelyavs> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | crypto-team, dbelyavs, dwalsh, jjelen, lkundrak, mattias.ellert, p, tm |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | Flags: | fedora-admin-xmlrpc:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | openssh-9.9p1-13.fc43 | Doc Type: | --- |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2025-03-18 18:11:58 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Lennart Poettering
2025-03-14 23:15:26 UTC
Also see: https://github.com/termstandard/colors?tab=readme-ov-file#checking-for-colorterm (i.e. i figure on the server config AcceptEnv= should also be updated) FWIW back in 2012 in Fedora we used COLORTERM to key whether >= 256 colors were supported. See https://fedoraproject.org/wiki/Features/256_Color_Terminals Use of that env var was quite ubiquitous at that time, and at that time we suggested/patched some less popular terminals to also set COLORTERM I'm quite surprised hearing that there are some problems with colors processing without this variable, speaking frankly. I didn't come across on it for a while. Could you please provide an example when we meet this problem? Consider this: take a current fedora VM, boot it in qemu with serial console or hvc console, log into the serial/hvc. You'll find TERM=vt220, because we have no better info, this is a reasonable safe fallback that is relatively "modern" but available in everybody's terminfo. If you type "ls" now, you'll see no coloring being used, even though fedora defaults to color. With a git version of systemd however it does work, because it sets COLORTERM=truecolor too, if it defaults TERM=vt220. `ls` cares about $COLORTERM, like a myriad other tools. Except if you then ssh from that machine elsewhere (for example via "localhost" into itself). Because $TERM is propagated, but $COLORTERM is not, if you type `ls` then all the color is gone again. Sniff! "sudo" has been propagating COLORTERM since 2007 because of this. See https://github.com/sudo-project/sudo/commit/f221ba2300ea526192d575bf81db60211b362e15. Many other tools too. ssh unfortunately not though. to emulate the above without actually firing up a VM, try this from your shell: ```sh export TERM=vt220 unset COLORTERM eval $(dircolors) ls / ``` this will show an uncolorized ls. now do: ```sh export TERM=vt220 export COLORTERM=truecolor eval $(dircolors) ls / ``` now it's colorized. to verify that `sudo` propagates COLORTERM: ```sh TERM=vt220 COLORTERM=truecolor sudo -s echo $TERM $COLORTERM eval $(dircolors) ls ``` to verify that `ssh` does not propagate COLORTERM: ```sh TERM=v220 COLORTERM=truecolor ssh localhost echo $TERM $COLORTERM eval $(dircolors) ls ``` FEDORA-2025-49ccf029e9 (openssh-9.9p1-13.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-49ccf029e9 Excellent! Thank you so much! That was quick! Much appreciated! FEDORA-2025-49ccf029e9 (openssh-9.9p1-13.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report. |