> This seems like quite an invasive change. It has not yet been accepted upstream.
Nope, but reviewed and approved by at least one upstream developer both upstream and downstream (Tobias), while we're using it in noble for few months already with no issue reported so far. > 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. It doesn't touch PAM authentication by default, it's triggered by (some) PAM authentications. However, we can definitely get the security team in the loop here. > 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? I can clarify this in the description, but showing emoji that's clearly not the root cause, it's just the simplest and easier reproducer for this issue. Indeed, the reason for this is that in authd we are presenting a qrcode to perform weblogin and that doesn't work. We are basically affected by the same issue of https://github.com/ubuntu/authd/issues/497 The test case for it, in a such complex setup isn't as easy to test as the minimal reproducer that it's enough to cover the fix and to ensure there are no regressions in the normal behavior. We're going to handle that in the openssh server too (starting from noble), but still we should be able to support this capability in the right way in ubuntu. > 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. Well, all the bug fixes can be features, if you are strict enough. But this is not the case IMHO, the client is clearly broken at handling some particular text, we're fixing it. There are no changes in behavior, and other major SSH clients (putty) handle this case already as the proposed change does for years. >> > 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. PAM info messsages are exposed as generic SSH messages, they're the only ones of this kind AFAIK, but I wanted to be generic enough so that normal ssh usage should be checked too. >> 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? PAM it is, but keyboard interactive authentication (which is the only case that triggers these messages) is not, so the change doesn't affect PAM behavior of ssh per se, only if the server has enabled keyboard interactive authentication, which PAM modules can trigger. But again, this is not default. ** Bug watch added: github.com/ubuntu/authd/issues #497 https://github.com/ubuntu/authd/issues/497 -- 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
