LWN: Comments on "Ubuntu 21.10 (Impish Indri) released"

Ubuntu 21.10 (Impish Indri) released

daenzer — Thu, 18 Nov 2021 08:25:41 +0000

Remote X works with Xwayland exactly the same as with Xorg, so not sure what you mean by that.

Ubuntu 21.10 (Impish Indri) released

JanC_ — Tue, 02 Nov 2021 15:36:30 +0000

You could try https://ubuntuhandbook.org/index.php/2021/05/enable-pipew...

Ubuntu 21.10 (Impish Indri) released

JanC_ — Tue, 02 Nov 2021 14:53:21 +0000

The post I answered to specifically mentions “But at least Wayland is finally getting there by default in most cases”, and I was pointing out that while some people have been pushing for people to switch to Wayland by default for many years, it still has regressions (for some people) today.

You won't have issues with that when using Sway, I suppose, but e.g. under Gnome there are still regressions with window positioning in several applications when run on top of Wayland instead of Xorg.

And now people are pushing for another significant change again, which will almost certainly cause regressions for a while too, so acting surprised when some people want to hold off for a while shouldn't be surprising…

Ubuntu 21.10 (Impish Indri) released

mgedmin — Thu, 21 Oct 2021 14:47:33 +0000

I'm on 21.10, listening to audio through my bluetooth headset (Bose QC35 II), and pactl list | grep codec prints

bluetooth.codec = "sbc"

So whatever LDAC/AptX support is supposed to be, it doesn't seem to be working out of the box.

Ubuntu 21.10 (Impish Indri) released

jpritikin73 — Mon, 18 Oct 2021 20:36:37 +0000

Can Pipewire audio be enabled to try out? Has anybody published a tutorial how to?

Ubuntu 21.10 (Impish Indri) released

foom — Mon, 18 Oct 2021 15:24:51 +0000

Firstly, SSH does not do terminal emulation. Adding terminal escape sequence filtering to SSH would be a major change.

Additionally, this is not simply an issue of SSH. There are numerous ways to get untrusted and unfiltered text printed to your terminal besides just ssh. E.g. "nc host", "cat file", "curl url", (or even "mpg123" per the GNOME issue linked earlier).

But, finally, your terminal emulator is indeed functioning as a security boundary these days. The expectation of (most) users is that printing arbitrary text to the terminal cannot materially affect the rest of the system, outside limited and well-defined aspects. (Clipboard access does seem like a reasonable candidate to be one of those, as long as it's under the user's control -- which is what the entire discussion on the gnome bug is about).

Historically, it was certainly not always the case that the terminal emulator authors considered the terminal emulator to be a security boundary (see, f.ex. the addition of the OSC 3 sequence to xterm back in 1999, which lets you set an arbitrary X property on the top-level xterm window!). There have been a variety of control sequences in xterm which had to be disabled in the intervening years, as part of that transition of expectations.

See e.g. these issues:
https://www.debian.org/security/2003/dsa-380 (remote command execution, via the combination of "set window title" followed by "get window title" printing the command back to a shell prompt.)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510030 (same, via a DECRQSS parse-error similarly printing back the input text -- plus a variety of other badness).

Fortunately when the OSC52 "get clipboard" sequence was invented, they decided to encode the contents with base64, which at least avoids the whole "remote command execution" set of issues.

Ubuntu 21.10 (Impish Indri) released

ibukanov — Mon, 18 Oct 2021 06:31:26 +0000

There is a reasonable way to implement OSC 52 in the terminal with rather minimal risk even in case of a malicious code running in the container. Allow copy-paste only when the terminal has focus and only within one second or less after a press on a physical key. For copy also require that content of the clipboard was pasted there within, say, 10 seconds after the last copy operation. Alternatively to copy the terminal emulator may require first to press a special keyboard shortcut to make the content of the keyboard available for OSC 52 access. The latter will be similar to how qube-os implements cut-and-paste between virtual machines.

Until such functionality is implemented in a terminal it is reasonable to implement it in a filtering application.

Ubuntu 21.10 (Impish Indri) released

NYKevin — Mon, 18 Oct 2021 01:22:00 +0000

Sure, that works too. My main point is that the GUI terminal emulator is generally not a great place to put the security boundary, because whatever app runs inside of it already has the technical ability to read the clipboard anyway. If the user decides to run some application, and that app prints an OSC 52 code which steals the clipboard contents, then there are really only two cases here:

* The user is screwed anyway because they just executed malware. Malware can already steal your clipboard contents by other means, and do plenty of much nastier things besides.
* The app is trusted (not malware), but failed to implement an appropriate security boundary between the user and some untrusted system. Then this is a matter of the app's security model either being inadequate or not matching the user's desired security model. That's none of gnome-terminal's business.

We can argue until the cows come home about the proper way to implement this security boundary, but I think it's pretty clear that the answer is not "filter the codes out at the GUI terminal emulator on the local system."

Ubuntu 21.10 (Impish Indri) released

mathstuf — Mon, 18 Oct 2021 01:09:18 +0000

Tmux has its own set of buffers (prefix-[) you can use to sling text around without having to play around with X buffers. You can also insert things yourself into the buffer stack using `tmux set-buffer`. There's also `tmux choose-buffer` to handle pick from deeper in the stack.

Ubuntu 21.10 (Impish Indri) released

ibukanov — Sun, 17 Oct 2021 19:29:14 +0000

With not-so-trusted containers one may not use ssh to enter them. So a better solution will be a utility that can be used to wrap any command including ssh or container enter command. That utility then filters OSC 52 and do sensible things with copy-paste before forwarding data to the terminal application.

Ubuntu 21.10 (Impish Indri) released

NYKevin — Sun, 17 Oct 2021 19:03:18 +0000

This is only a problem to the extent that the remote system is untrusted. While I agree that some people do need to SSH into untrusted systems, that is not a problem which I personally care about, so I'm really not enthused with the "for security reasons, we must not support OSC 52 at all" approach.

IMHO the correct way for this to work is for SSH to filter these sequences depending on a policy which the user can set, and gnome-terminal should blindly pass through anything which SSH gives it. My rationale:

1. In principle, SSH can already read the local system's clipboard anyway, because it is running on the local system. So gnome-terminal is not functioning as a security boundary in the first place. If we really wanted to, we could have SSH recognize and implement OSC 52 sequences behind gnome-terminal's back (but then SSH would need to be in the business of interfacing with X and Wayland, which is probably undesirable).
2. Any GUI app running on the local system (or, in the case of X11, any app which renders to the local X server, regardless of where the X client is running) can also read the clipboard more or less freely. If the user runs an app which steals the clipboard contents and uses them for nefarious purposes, we don't blame X or Wayland for allowing this. Running a local app inside of the terminal (such as SSH) should be no different.
3. SSH needs to do pty allocation etc., so it's already in the business of terminal emulation anyway. Adding OSC 52 filtering wouldn't be too much extra work.
4. SSH knows what host we're connected to. gnome-terminal probably doesn't.
5. This is how X11 forwarding has historically worked (consider -X vs. -Y). SSH is the security boundary, and the local terminal emulator is just responsible for rendering text to the screen.

Ubuntu 21.10 (Impish Indri) released

ballombe — Sun, 17 Oct 2021 16:53:16 +0000

Indeed! You just need to install gpm or consolation.

Ubuntu 21.10 (Impish Indri) released

ibukanov — Sun, 17 Oct 2021 16:42:49 +0000

This is of no use for remote terminal sessions. For those the application must use terminal control sequences to do copy/paste and then the terminal emulator should map those to local clipboard. A workaround is to forward X11, but that is not a good solution if remote system is not particularly trusted.

Obviously a naive implementation of the paste operation will be a security disaster since it will allow the remote system to read the local clipboard. This is probably a reason Gnome terminal has not yet implemented those sequences. But one can do reasonable compromises with usability/security for the paste and for copy there is really no excuses.

Ubuntu 21.10 (Impish Indri) released

shruggy — Sun, 17 Oct 2021 15:02:27 +0000

> But I don't think vim has code to deal with anything Wayland...?
Clipboard handling is one of the few areas where Neovim considerably differs from Vim. nvim relies on external providers for this: https://neovim.io/doc/user/provider.html#provider-clipboard

For Wayland, that would be https://github.com/bugaevc/wl-clipboard

Ubuntu 21.10 (Impish Indri) released

bjartur — Sun, 17 Oct 2021 14:44:55 +0000

The Linux teletype terminal emulator, Ctrl-Alt-Fn, has mouse support, complete with text selection, copy, and paste.

Ubuntu 21.10 (Impish Indri) released

NYKevin — Sun, 17 Oct 2021 09:21:27 +0000

> Out of curiosity, how does tmux handle this if you run it in a TTY?

I'm not sure what you mean by this. I was able to come up with these interpretations, but none of them make sense to me:

* Run the tmux client under a virtual console (Ctrl+Alt+Fn) (because those are TTY1-N for some N depending on your system), or some other thing for which isatty(3) returns 1 (because a TTY is anything which isatty, right?). But tmux runs on the remote system, so it will generally be running under a pty created by sshd. Running it under something else isn't really a thing that I can reasonably do.
* Run the tmux server under such a thing. But the tmux server is not designed to have a controlling terminal at all, as far as I can tell anyway.
* Run SSH under a virtual console (Ctrl+Alt+Fn) which is not already being used to run X11/Wayland. But then you don't have a GUI at all, so regular copy/pasting is out of the question. You can still use copy-mode, of course, but that's entirely keyboard-controlled, and the "clipboard" lives entirely within tmux, so no GUI support is required.
* Run SSH under some other thing for which isatty(3) returns 1. But I can't figure out what that "other thing" would be.
* Pass the -t flag to SSH. I'm already doing that. IIRC tmux will flatly refuse to run if there's no controlling terminal, or if $TERM is not set.

Ubuntu 21.10 (Impish Indri) released

rsidd — Sun, 17 Oct 2021 08:29:31 +0000

Hm. Seems to be a tmux issue, specific to multiple pane setup? I use screen sometimes, not tmux. Anyway, it's a bit more complicated than what I usually do!

I think it is this sort of "power usage" case that wayland breaks.

Out of curiosity, how does tmux handle this if you run it in a TTY?

Ubuntu 21.10 (Impish Indri) released

NYKevin — Sun, 17 Oct 2021 03:51:29 +0000

> 1. It's one-way.

It occurred to me that this is insufficiently explicit, so let me elaborate: If you use tmux with multiple panes, the obvious solution of "highlight the text you want to copy, then press Ctrl+Shift+C" doesn't work, because you'll get a bunch of extra whitespace and/or box-drawing characters thrown in, and for vertical panes, you might even copy part of another pane altogether. tmux does have a mostly-seamless workaround for this, but it too depends on X11 forwarding (so that it knows where the mouse is and can intercept mouse events).

Ubuntu 21.10 (Impish Indri) released

NYKevin — Sun, 17 Oct 2021 03:32:36 +0000

> For a ssh session, middle button paste works, and so does shift-ctrl-c and shift-ctrl-v (in xfce4-terminal), but that's local clipboard.

Actually, that's exactly what I want to do, except for two problems:

1. It's one-way.
2. It's not easily composable with vim's put/yank/etc. operators, nor with its motions. You can sorta kinda get around this by using insert mode (using change instead of put), but you have to do :set paste if you actually want it to behave correctly, and frankly that's a PITA.

If you enable X11 forwarding, then vim's quoteplus and quotestar registers directly map to your local X11 clipboards (CLIPBOARD and PRIMARY, respectively), and as vim registers, they are fully composable with everything you might reasonably want to do. But I don't think vim has code to deal with anything Wayland...? Regardless, Wayland has no equivalent to X11 forwarding (that I'm aware of), so it's a moot point.

> Also, on a vnc session with wayvnc (remote) and xtigervncviewer (local), copy-paste works from local to remote or vice versa. The vnc is blazing fast (seems much faster than x11vnc which I used earlier), and I can make it fullscreen and "pass through" my key strokes so that it feels exactly as if I am sitting at the remote machine.

SSH is low-dependency. When half the world has burned down, I can still SSH into my machine and fix things. Remote desktop applications, regardless of which one you want to use, are necessarily going to depend on additional infrastructure that has a higher chance of breaking or not being present (e.g. you can SSH into a headless machine). I care about this because I'm a Site Reliability Engineer, and worrying about "what if everything is down?" is a significant chunk of what they pay me to do.

Ubuntu 21.10 (Impish Indri) released

mroche — Sat, 16 Oct 2021 23:00:56 +0000

> Zoom client doesn't support screensharing on my setup, but claims to on gnome+wayland.

Supposedly this won't be the case for GNOME 41+ unless Zoom modifies what APIs they're using.

https://nitter.net/det_conan_kudo/status/1446196846548901896

Ubuntu 21.10 (Impish Indri) released

rsidd — Sat, 16 Oct 2021 05:47:07 +0000

I'm not really familiar with this. For a ssh session, middle button paste works, and so does shift-ctrl-c and shift-ctrl-v (in xfce4-terminal), but that's local clipboard. Also, on a vnc session with wayvnc (remote) and xtigervncviewer (local), copy-paste works from local to remote or vice versa. The vnc is blazing fast (seems much faster than x11vnc which I used earlier), and I can make it fullscreen and "pass through" my key strokes so that it feels exactly as if I am sitting at the remote machine.

Ubuntu 21.10 (Impish Indri) released

NYKevin — Sat, 16 Oct 2021 04:44:09 +0000

Currently, gnome-terminal does not provide support for OSC 52 escape codes.[1] As a result, so far as I can tell, there is no reliable way for an application (such as vim) running on a remote machine (over SSH) to interact with the clipboard of the local host (e.g. for vim's quoteplus and quotestar registers) if the local host is not running X11 and/or X11 forwarding is not enabled. I am not aware of any Wayland-equivalent to this exact combination of functionality, but I would be happy to be mistaken about this.

(Perhaps I should just drop gnome-terminal and switch to something which is not a GNOME app? I'm already on xfce so it wouldn't be that big of a deal anyway...)

[1]: https://gitlab.gnome.org/GNOME/vte/-/issues/2495

Ubuntu 21.10 (Impish Indri) released

rsidd — Sat, 16 Oct 2021 02:19:46 +0000

I'm not sure how pipewire is related to wayland (except for video call screen sharing, where as noted elsewhere here, Ubuntu does use pipewire).

I switched to wayland (sway) a few weeks ago, from i3, after a few false starts. In basically everything, either it just works, or there is a wayland equivalent that is actually better.

Two exceptions:

video call screen sharing. Works for full screen but not individual windows. Doesn't work at all for zoom client (which apparently uses a gnome-specific protocol); does work for zoom in chrome browser.
Screen mirroring to external display. Not supported by sway so far, but there's a workaround using vnc, which is arguably better. (Otherwise, external display handling is good on i3, better on sway.)

Mainly, I don't know why, but resource usage seems noticeably less on sway/wayland, laptop runs cooler, battery lasts longer.

This is a 7 month old laptop running Ubuntu 21.04 since the start (beta version). I haven't yet updated to 21.10.

Ubuntu 21.10 (Impish Indri) released

JanC_ — Fri, 15 Oct 2021 22:51:33 +0000

Considering Wayland is *still* causing UX regressions (for everyday users; I’m not even talking here about remote X or the ability to restart Gnome Shell once in a while to get rid of leaked/fragmented memory), are you really all that surprised?

Ubuntu 21.10 (Impish Indri) released

andrewsh — Fri, 15 Oct 2021 20:32:41 +0000

Well, Ubuntu does ship PipeWire, it just isn’t the default.

Ubuntu 21.10 (Impish Indri) released

Cyberax — Fri, 15 Oct 2021 10:43:26 +0000

I guess they are still burned by the experience of adopting PulseAudio very early in its life.

Ubuntu 21.10 (Impish Indri) released

smcv — Fri, 15 Oct 2021 09:16:17 +0000

> Also, on a wayland session pipewire is required for screensharing in video calls, in my understanding. So I don't know how ubuntu is doing that.

If it's anything like Debian 11, they'll be using Pipewire for video (screen sharing etc.), but not for audio yet. That's the more conservative approach to adopting Pipewire, and is the same thing distributions like Fedora did in the past.

Ubuntu 21.10 (Impish Indri) released

rsidd — Fri, 15 Oct 2021 09:01:33 +0000

Also, on a wayland session pipewire is required for screensharing in video calls, in my understanding. So I don't know how ubuntu is doing that. I use ubuntu 21.04, not yet upgraded; currently using sway (wayland), not gnome/unity. Full screen sharing works (at least in browser-based video calls) after lots of tweaking. Zoom client doesn't support screensharing on my setup, but claims to on gnome+wayland. Zoom add-on in chrome browser does support screensharing.

Ubuntu 21.10 (Impish Indri) released

theobald — Fri, 15 Oct 2021 08:46:32 +0000

I also find this slightly surprising. At least in Fedora land the story is the Pulse doesn't, and cannot be made to, support browser sandboxes. As far as I have understood it at least.

Ubuntu 21.10 (Impish Indri) released

ibukanov — Fri, 15 Oct 2021 08:39:50 +0000

So Ubuntu decided not to go with PipeWire audio and stick with Pulse. Which means no PipeWire in the next Ubuntu stable. But at least Wayland is finally getting there by default in most cases.

Ubuntu 21.10 (Impish Indri) released

ttuttle — Fri, 15 Oct 2021 06:15:41 +0000

Am I understanding correctly that versions of Ubuntu *before* 21.10 included versions of PulseAudio that supported only SBC, the baseline A2DP codec?