Mh, yeah looks like the terminal filtering is something we should do in openssh anyways, at various levels though.
Fact is that if a server is malicious, nothing prevents to do the same through a simpler sshd banner or command, that is still able to act on remote terminal. It's true that PAM modules are sneakier than that, as they may be checked less than the pure openssh server configuration, but still it's all server duty, and if compromised (intentionally or not), it can be still a driver for such issues in the current state. ASCII based solutions for qr code are acceptable, they can just quite big though. Being a problem if you use them from a tty. However that's another possibility we were considering already. Regarding upstream diversion, I totally agree (and I would have loved to avoid it)... Ideally we had a plan, and the fix was proposed way earlier upstream than downstream. So we were just waiting... -- 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
