This change makes me uneasy: - I see no terminal-aware filtering applied in the notify_start() -> xvasprintf() -> writemsg() -> write() path. The remote server may not be entirely untrusted but it's also not exactly trusted, either, especially on the first use. There's a long and glorious history of surprising outcomes due to terminal escape sequences https://www.cyberark.com/resources/threat-research-blog/dont-trust-this- title-abusing-terminal-emulators-with-ansi-escape-characters
- I'm not sure it's even necessary: my phone was easily able to read pure-ascii QR codes as easily as the (admittedly much better looking) utf-8 based codes. Try a few: sudo apt install qrencode u=`cat /proc/sys/kernel/random/uuid` ; for t in ANSI ANSI256 ASCII ASCIIi UTF8 ANSIUTF8 ; do qrencode -t $t $u ; done ; echo $u ; unset u Are ascii-encoded qr codes known to be insufficient? - As for the actual code changes, they seemed fairly straightforward, and I found no issues. I'm very wary about undoing a safety mechanism from the past, put in place by people who thought about this significantly more than I have. - Upstream might have been engaging for a while but now appears entirely silent. This reminds me too much of dpkg+zstd, where a similar train of engagement lead to Ubuntu forking the dpkg ecosystem and carrying a patch without a clear way to reunify the ecosystem. Will we do the same to OpenSSH? (We might have already passed this point if we chose to ship this in Noble rather than wait for Oracular to test this out.) Thanks -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2077576 Title: SSH client doesn't handle properly non-ASCII chars To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2077576/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
