This seems like quite an invasive change. It has not yet been accepted upstream. It touches PAM, and it looks to me like it might affect behaviour before authentication is complete. It affects escaping. Injection of malicious data into a stream to be parsed by the terminal has security implications. There is no security analysis or opinion of the security team presented.
If we're going to make changes in stable releases, or even a distribution patch, I think we need particularly strong justification given the above factors. To consider that, we need to consider the actual impact to users. But that doesn't seem to have been presented here. > Non-ascii visible chars are not properly rendered by clients, showing their octal visualization. That's not really an explanation of impact to user. What are we looking at here? Just the ability to include emoji in messages that, according to the SRU documentation provided, won't even be seen by the user? That sounds like a feature to me, and therefore doesn't seem appropriate to change a stable release for given that no justification has been provided. > SSH info messages are not shown by the client. This seems to be contradicted by the provided Test Plan, which runs the client and checks for the message. Please explain. > These kind of messages are normally shown only when PAM is enabled in the server side, so it should not affect the normal behavior. PAM is enabled by default on openssh on Ubuntu, no? For SRU purposes, -1 based on the lack of an acceptable justification to SRU. If there is one, please present it, otherwise these uploads should be rejected from the queue. ** Merge proposal linked: https://code.launchpad.net/~3v1n0/ubuntu/+source/openssh/+git/openssh/+merge/460160 ** Changed in: openssh (Ubuntu Focal) Status: Fix Committed => Incomplete ** Changed in: openssh (Ubuntu Jammy) Status: Fix Committed => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2077576 Title: SSH client doesn't handle properly non-ASCII chars Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Focal: Incomplete Status in openssh source package in Jammy: Incomplete Status in openssh source package in Noble: Fix Released Bug description: [ Impact ] Non-ascii visible chars are not properly rendered by clients, showing their octal visualization. Such as: Hello SSHD! We love \360\237\215\225! [ Test case ] ## Server preparation Enable PAM and keyboard interactive authentication in a ssh server: Add a configuration file such as: /etc/ssh/sshd_config.d/test-ssh-pam.conf Containing: UsePAM yes KbdInteractiveAuthentication yes Restart the server: sudo systemctl restart ssh.service Edit the sshd PAM configuration file, adding as first line: auth requisite pam_echo.so Hello SSHD! We love 🍕! Can be done with the command: sudo sed '1 i\auth requisite pam_echo.so Hello SSHD! We love 🍕!' -i /etc/pam.d/sshd ## Client test In the same host: ssh -o PubkeyAuthentication=no \ -o PasswordAuthentication=no \ -o PreferredAuthentications=keyboard-interactive \ $USER@localhost The client should show: Hello SSHD-dev in devel schroot! Want some 🍕? ($USER@localhost) Password: Retry the same with another host and without keyboard authentication enabled in the server side. ## Cleanup Revert the changes done in the cleanup phase, after test is done sudo sed '/pam_echo\.so/d' -i /etc/pam.d/sshd sudo rm /etc/ssh/sshd_config.d/test-ssh-pam.conf [ Regression potential ] SSH info messages are not shown by the client. These kind of messages are normally shown only when PAM is enabled in the server side, so it should not affect the normal behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2077576/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
