Re: Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

Jonathan Dowland
Dear Simon,

Thanks for taking the time to file this, I had been meaning to in the
week leading up to Easter but I was unable to get much computer time.

On Sat, Apr 20, 2019 at 08:44:42PM +0100, Simon McVittie wrote:
> but I think it would be good to reassess the costs and benefits
>of Wayland vs. X11 by default, and either make a positive decision to
>keep Wayland as the default, or diverge from upstream and switch back
>to Xorg by default like Debian stretch and Ubuntu 18.04 did.

The decision as to whether GNOME-in-Debian defaults to Wayland or X has
repercussions beyond a GNOME perspective, because GNOME is the default desktop
for Debian. I think the "bar" that must be met for a change of default display
system from X to Wayland for the default Debian desktop is higher than just
for GNOME itself: Debian is a rich ecosystem of thousands of packages from
lots of communities, including GNOME and others; I believe it's a
reasonable expectation of a user that the default desktop system works
reliably with the vast majority of packages within our repositories,
not just those designed specifically for GNOME.

My personal impression of GNOME/Wayland is that it's not up to that standard
just yet (I experience lots of problems when I have tried to evaluate it, but I
have not yet filed nor investigated each of them further, and I should).  But I
would worry about making that judgement myself because I'm not at the cutting
edge of this area. Ubuntu deciding that it wasn't ready for 18.04 was notable
to me; if it wasn't suitable for them, with a narrower focus than Debian, then
I would think it not yet suitable for us either.

What triggered me to say something was learning that some packages were being
autoremoved, with the justification that they don't work well with the (now)
default desktop system. "synaptic" was the first, and a very high profile one
at that (but I think it has now been patched: #818366); another that I became
aware of was "tilde", but I have not performed an exhaustive search and I worry
there may be others. I did try "gparted" to be sure that worked (seems to)
since that's another "best in class" GUI app which was likely to have the same
problems as synaptic.

(I realise that it was neither the GNOME team nor the release team that decided
a package not working under Wayland should be RC, and that you do not
necessarily support that.)

What I would really like to see, please, is pointers to the criteria used in
the decision making for switching to Wayland-for-default. What was considered
important? Is there any consensus with the position I outline in my first
paragraph above? Was this decision made before or after Ubuntu abandoned it for
18.04? Do we know what specific criteria Ubuntu used, and how does it differ to
ours?

>From what I have seen or discovered so far, I argue that GNOME-Wayland is not
yet a suitable choice for the default desktop, and would suggest the simplest
fix would be to revert to GNOME/X11 for Buster and re-evaluate for the next
release.

>(As the maintainer of flatpak in Debian, I would be sad to see us go
>back to a display protocol where every app can copy other apps' window
>contents, inject fake input events or be a keylogger... but I'm also
>aware that some programs rely on X11 not providing meaningful privilege
>separation, and that the Wayland compositor model exacerbates any bugs
>that cause GNOME Shell to crash.)

I can appreciate your position and the improved secure isolation of independent
graphical apps in the Wayland stack is very attractive. I just want to be sure
that we as a project are effectively weighing these new advantages against the
costs. It's important to me that we are not throwing out packages (and the
corresponding work that other developers have put into making Debian as great
as possible), or making the experience of using the wealth of packages within
Debian less seamless for new users, without being aware at a project level that
we are doing it.  I have no axe to grind against Wayland and would never say
"never" to it.


Best wishes

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

Re: Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

Jonathan Dowland
Folks,

On the subject of Wayland's readiness to be the default Debian desktop display
system for Buster, I've just filed #928002 to track problems with drag-and-drop
between X and non-X applications under Wayland (presently filed against firefox
but I think it probably belongs somewhere else).

Reply | Threaded
Open this post in threaded view
|

Re: Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

Simon McVittie-7
On Fri, 26 Apr 2019 at 10:50:10 +0100, Jonathan Dowland wrote:
> On the subject of Wayland's readiness to be the default Debian desktop display
> system for Buster, I've just filed #928002 to track problems with drag-and-drop
> between X and non-X applications under Wayland (presently filed against firefox
> but I think it probably belongs somewhere else).

I forgot to mention before that I've been using a usertag to mark
Wayland-related bugs:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=wayland&user=pkg-gnome-maintainers%40lists.alioth.debian.org

I've usertagged #928002 accordingly. Please usertag any similar bugs that
you report or notice.

(Not all of these are regressions that would be addressed by going back
to X11.)

    smcv

Reply | Threaded
Open this post in threaded view
|

Re: Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

Jonathan Dowland
On Fri, Apr 26, 2019 at 11:55:00AM +0100, Simon McVittie wrote:
>I forgot to mention before that I've been using a usertag to mark
>Wayland-related bugs:
>https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=wayland&user=pkg-gnome-maintainers%40lists.alioth.debian.org
>
>I've usertagged #928002 accordingly. Please usertag any similar bugs that
>you report or notice.

Thanks Simon, hopefully I've just done that for #928030 (filling up / results in
wayland session crashing + gdm3 not working until disk space is freed)

>(Not all of these are regressions that would be addressed by going back
>to X11.)

Perhaps we should use another usertag to separate out those ones, since those
are the ones that would be pertinent for this decision. (This would apply to
#928002 and #928030). May I propose "x11regression" under the same BTS user?



--
Jonathan Dowland

Reply | Threaded
Open this post in threaded view
|

Re: Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

Simon McVittie-7
In reply to this post by Jonathan Dowland
> What I would really like to see, please, is pointers to the criteria used in
> the decision making for switching to Wayland-for-default.

I cannot give you those criteria. I don't think there was any sort of
formal document listing requirements that had to be met, any more than
there was for stretch (where we reluctantly decided that Wayland mode
had too many issues at that stage, and shipped a version of GNOME for
which the upstream default was Wayland mode, but patched it to have
X11 as default and Wayland as an option for the adventurous). Laurent
Bigonville said on IRC that he was the one who reverted our patch that
switched the default to X11 mode, in 2017, so perhaps he can clarify
the factors that went into this decision.

(Or if you mean the criteria used by GNOME upstream, I suggest asking
them.)

The status quo of GNOME is that the default *is* Wayland, and if we want
the default in Debian to be X11 instead, we have to patch something (as
we did in stretch). I firmly believe that distributions sometimes need
to diverge from their upstreams, but that any such divergence needs to
have a justification, so I could turn this around: what are the criteria
that you believe should be used in the decision making for switching to
X11-for-default? (I'm not sure which component would need to change if
we wanted to go back to the stretch situation: most likely gnome-session,
or perhpas gdm3.)

My understanding (again, I am not an expert and I don't have an infallible
overview) is that the advantages and disadvantages of Wayland mode by
default go something like this. You'll notice that many things turn up
in both lists, because they're an advantage or a disadvantage or both,
depending how you look at them.

Advantages of Wayland mode over X11 mode
----------------------------------------

The Wayland protocol is suitable for privilege separation: ordinary
apps cannot be keyloggers, or forge input events, or copy each others'
window contents. With X11, if a sandboxed app (Flatpak, Snap, etc.)
can draw its own windows, then it can spy on other apps or send input
to them. Deliberately using a protocol that doesn't have useful privilege
separation doesn't necessarily send a great message about the importance
we put on privacy/security.
- Rebuttal: some X11 apps want to do those things for non-malicious
  reasons; see below. In principle sandboxing frameworks could filter
  X11 access with something like Xpra, although I am not aware of a
  concrete implementation.

If the Wayland compositor (GNOME Shell) crashes, that can't result
in a lock-screen bypass, because the compositor is the display-server
equivalent: if there is a crash bug that is triggerable by an attacker on
a locked session, it is denial of service (end of session), which, while
undesirable, is less bad than the privilege escalation (ability to see
or manipulate unintended windows) that would often be seen when an X11
compositor/WM crashes.
- Rebuttal: denial of service is also bad, and crashes can occur for
  reasons other than malice.

There might be performance advantages for native Wayland apps such as
GTK3 apps, from being able to use a more direct rendering path that
is a better match for how the hardware works.
- Rebuttal: many apps aren't native Wayland apps and won't benefit
  from this. Wayland is relatively new, so perhaps these performance
  advantages are only theoretical at this stage.

Wayland mode has been GNOME's upstream default for several years, so
it's what upstream will be expecting, and is the most likely to get
useful feedback on bug reports.

Full-screen apps (games) can't arbitrarily change your screen resolution,
then crash without changing it back.
- Rebuttal: they also can't change your screen resolution even if you
  want them to.

There are some X11-specific bugs.
- Rebuttal: there are also some Wayland-specific bugs.

Advantages of X11 mode over Wayland mode
----------------------------------------

Some X11 apps want to do things that Wayland doesn't normally allow:
capture global keyboard shortcuts (which involves doing the same thing
a keylogger would do), or create input events (which involves doing the
same thing you'd do if maliciously forging input events), or take
screenshots or capture video (e.g. for screencasting or screen-sharing)
via X11 (which involves doing the same things you'd do if you were
maliciously spying on other apps).
- Rebuttal: it's good when apps do these things with the user's knowledge
  and permission, but very bad when they do them maliciously (see above),
  and the display protocol is not in an a position to judge intent. In
  Wayland mode, many of these things can be done via D-Bus by a
  sufficiently-privileged app, and any useful app-sandboxing framework
  already needs to filter access to the D-Bus session bus anyway;
  however, this does require code changes in the privileged app.

If the X11 compositing manager/window manager (GNOME Shell) crashes, the
X server and the X session in general continue to run, and the session
manager (GNOME Shell) has the opportunity to restart the compositing
manager/window manager.
- Rebuttal: While the Shell is restarting, apps become visible even if
  they should not have been, which can be a security problem if an
  attacker can trigger a crash in the lock screen (see above).

Some of the protocols used by X11 apps are not emulated well by the
combination of Xwayland and GNOME Shell: in particular I've seen reports
of intermittent issues with drag-and-drop between native Wayland apps
and X11 apps. PRIMARY selection (middle-click paste) and pointer barriers
("mouse capture" typically used by games) were also problematic in older
versions, and if I remember correctly they were the major blockers for
Wayland-by-default in stretch, but I think those were fixed shortly
after stretch.

X11 typically allows root processes to draw windows on other users'
displays. Applications that don't have privilege separation, such as
synaptic, rely on this. Wayland restricts the display to be used by
a matching uid only, and Xwayland is typically configured to do the same.
- Rebuttal: Applications that do this are running a full graphical
  toolkit as the most privileged user, so bugs (or privilege escalation
  opportunities, if the owner of the display is not already totally
  trusted) can be disastrous. Graphical toolkits typically (have to)
  trust their display server completely, so it is very likely that
  applications that do this can be subverted by the owner of the display
  or by their other apps, and any privilege separation that might appear
  to result from the use of su/sudo/pkexec is likely to be breakable.

There might be performance advantages for X11 apps in being able to go
app -> Xorg -> hardware, instead of app -> Xwayland -> GNOME Shell ->
hardware.
- Rebuttal: X11 compositing is sufficiently complicated that I could
  well believe that these performance advantages might be small or
  nonexistent (in particular, GNOME Shell ends up compositing the app's
  window into its scene graph either way).

Some apps (such as historical versions of gVim and pasystray) use a
toolkit like GTK that is capable of using both X11 and Wayland, but
have the bug that they blindly assume that every display is an X11
display. These apps will crash or otherwise misbehave on Wayland, unless
they are patched to force use of GTK's X11 backend (as gVim and
pasystray were).
- Rebuttal: these apps were always making unwarranted assumptions,
  which would be equally untrue for e.g. Mir, and the solution is one
  line of code.

X11 has built-in network forwarding.
- Rebuttal: it works decreasingly well as apps' rendering moves from
  the X11 server to the client. X was designed to work the way apps
  worked in the 80s (requesting high-level drawing operations that made
  sense to a 1980s GUI designer within the constraints of contemporary
  hardware, like "draw a stippled rectangle"); Wayland is designed to
  work the way graphical toolkits, games, etc. work in practice now (have
  a drawable/surface/texture representing the window, and draw on it).

There are some Wayland-specific bugs.
- Rebuttal: there are also some X11-specific bugs.

---

Regards,
    smcv

Reply | Threaded
Open this post in threaded view
|

Re: Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

Jonathan Dowland
On Sat, Apr 27, 2019 at 11:49:24PM +0100, Simon McVittie wrote:
> The status quo of GNOME is that the default *is* Wayland, and if we want
> the default in Debian to be X11 instead, we have to patch something (as
> we did in stretch).
>
> I firmly believe that distributions sometimes need to diverge from
> their upstreams, but that any such divergence needs to have a
> justification, so I could turn this around: what are the criteria that
> you believe should be used in the decision making for switching to
> X11-for-default?

The direction of travel from an upstream GNOME perspective may indeed be
from Wayland-to-X11, but from a Debian release perspective, it's the
other way around: X11 is the display technology installed by default in
Debian and, due to GNOME's status as the default desktop environment,
adopting GNOME's default of Wayland has the wider repercussion of also
switching the Debian default.

I agree that divergences need justifications, but I also believe we need
to be mindful of the whole distribution when considering these matters.
It was not clear to me when I started this discussion, and it remains
unclarified now, whether due consideration to the distribution as a
whole has taken place for Buster.

For significant technology changes, Debian has traditionally taken a
slow, measured, reasoned and conservative approach to adoption. I think
it has come as a surprise to many (most?) developers that we are on
course to switch to Wayland at this point.

> My understanding (again, I am not an expert and I don't have an
> infallible overview) is that the advantages and disadvantages of
> Wayland mode by default go something like this.

This is an excellent summary, thank you. I agree with all of it. A
dimension you have not covered in your summary is regression: whether a
given behaviour for GNOME/Wayland is a regression with respect to the
behaviour of the default desktop in Debian. This facet is what
originally brought the matter to my attention.


--
Jonathan Dowland