update the flatpak to only use wayland, x11-fallback

[SnuggleCovenant]

Is your feature request related to a problem? Please describe.
the flatpak rates this app to be insecure partly because of the use of x11 by default which is insecure and allows, among other things, any other app currently running to play with the data pupgui uses in memory

Describe the solution you'd like
prioritize wayland, with x11-fallback for users without wayland

Describe alternatives you've considered
i've been running it as such on my side using flatseal

Additional context

[sonic2kk]

ProtonUp-Qt does already use Wayland by default if it is available (checked using Flatseal, and also verified with xeyes), though as you pointed out it does not use fallback-x11.

Where did you see the warning, exactly? I can't say I have seen this for ProtonUp-Qt or other applications. Just curious :-)

[SnuggleCovenant]

It's nice to know. Thank you for checking. You can see the warning in flathub https://flathub.org/apps/net.davidotek.pupgui2

I didn't mean to close this. I just made a github account for this and I'm unfamiliar with the UI.

[SnuggleCovenant]

reopen :S

[sonic2kk]

Ah, thanks, I didn't see this on Flathub.

This is interesting to see, aside from the X11 warning (or "legacy windowing system"), I'm interested in:

• "Can acquire arbitrary permissions" - Do you know what this refers to?
• "Can access hardware devices" - Unless I'm mistaken, ProtonUp-Qt shouldn't need to access anything like this (mics, speakers, etc) - I did see in the Flatpak manifest it specifies device=all but I'm not sure what this refers to.

Perhaps like with the X11 issue you brought up, this is just something ProtonUp-Qt has to mark?

The runtime issue was reported in #283 and will be fixed in flathub/net.davidotek.pupgui2#22. The warning

The remaining issues with file access are unavoidable really, as ProtonUp-Qt needs access specific files to accommodate game launchers. It also requires permissions to create some files like for SteamTinkerLaunch. You can see all the filesystem permissions here: https://github.com/flathub/net.davidotek.pupgui2/blob/master/net.davidotek.pupgui2.json#L12-L35

---

The reason I ask is that a "blanket PR" fixing up various Flatpak permissions in order to resolve as many of these warnings on Flathub as possible, would be more beneficial. Essentially discussing and fixing the Flatpak permissions generally :-)

[sonic2kk]

I tested very quickly with the X11 fallback flag (and with the X11 socket disabled), as well as by disabling devices=all, both toggled from Flatseal, and I have not noticed any problems so far.

I am not sure why Flathub is marking that ProtonUp-Qt can acquire arbitrary permissions, but aside from this, those two changes appear safe to make (pending further and much more in-depth testing).

[SnuggleCovenant]

I see "Can acquire arbitrary permissions" in gnome-software as well. I've found this discussion tangentially related: https://reddit.com/r/linux/comments/ybh241/comment/itm931g/?utm_source=share&utm_medium=web2x&context=3

An app is flagged as GS_APP_PERMISSIONS_ESCAPE_SANDBOX when the following permissions are requested:

• the xdg-data/flatpak/overrides:create filesystem permission:
  https://gitlab.gnome.org/GNOME/gnome-software/-/blob/42.4/plugins/flatpak/gs-flatpak.c#L259
• the org.freedesktop.Flatpak dbus talk permission:
  https://gitlab.gnome.org/GNOME/gnome-software/-/blob/42.4/plugins/flatpak/gs-flatpak.c#L288
• the org.freedesktop.impl.portal.PermissionStore dbus talk permission:
  https://gitlab.gnome.org/GNOME/gnome-software/-/blob/42.4/plugins/flatpak/gs-flatpak.c#L295

I would venture that flathub uses the same reference.

[sonic2kk]

Thanks for looking into that, probably not much can bee done about that "acquire arbitrary permissions" thing then, as this :create is used for SteamTinkerLaunch: https://github.com/flathub/net.davidotek.pupgui2/blob/master/net.davidotek.pupgui2.json#L31 (as for the name GNOME Software uses, "escape_sandbox", ProtonUp-Qt already has to do this to run the STL install script on SteamOS, see here)

This concern was raised before in this issue: flathub/net.davidotek.pupgui2#17

I also found out that ProtonUp-Qt needs devices=all for gamepad support: flathub/net.davidotek.pupgui2#14

So probably the only actionable change in this issue is to set the X11 fallback instead of using X11 by default.

[DavidoTek]

Thanks for looking into that, probably not much can bee done about that "acquire arbitrary permissions" thing then, as this :create is used for SteamTinkerLaunch: https://github.com/flathub/net.davidotek.pupgui2/blob/master/net.davidotek.pupgui2.json#L31 (as for the name GNOME Software uses, "escape_sandbox", ProtonUp-Qt already has to do this to run the STL install script on SteamOS, see here)

Yes, thanks for clarifying that.

So probably the only actionable change in this issue is to set the X11 fallback instead of using X11 by default.

I removed fallback-x11 on purpose because there was a regression with Qt as it would try to launch with x11 even if only wayland was available. We could create a PR and test whether this behavior is fixed with newer version of Qt/Wayland

flathub/net.davidotek.pupgui2@0a4fd4e

[sonic2kk]

I tested (via Flatseal) enabling the fallback-x11 socket and disabling the x11 socket, and ProtonUp-Qt appears to work. Creating a PR to build a Flatpak and find this out would be useful too, I had this configuration enabled while doing some testing for another issue and didn't realise until now, so it appears to work but more thorough testing would be good.

It seems like OP has tested this too without much issue as well.

Was there an upstream Qt/PySide issue for this that we could check on to see if this regression was marked as fixed?

[sonic2kk]

Just to document: This may be held back until #312 can be resolved, since that issue is a case where Wayland is causing a crash and fallback-x11 is required. Although manual intervention is still required in that case, if this was implemented, a user would have to switch off fallback-x11, which is an additional step to the current workaround which is simply to disable the wayland socket.