Wayland clipboard sync (xvfb -> Wayland)

[taoky]

Note: clipsync.py is generated by LLM.

Closes: #218.

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

❌ Test build was cancelled.

Help

• bot, build - Restart the test build
• bot, ping admins - Contact Flathub admins

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/232953/com.qq.QQ.flatpakref

Built for aarch64 and x86_64 architectures.

⚠️ Linter warnings:

Warnings can be promoted to errors in the future. Please try to resolve them.

• 'appstream-screenshot-missing-caption' warning found in linter repo check. Details: One or more screenshots are missing captions in the Metainfo file

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/233002/com.qq.QQ.flatpakref

Built for aarch64 and x86_64 architectures.

⚠️ Linter warnings:

Warnings can be promoted to errors in the future. Please try to resolve them.

• 'appstream-screenshot-missing-caption' warning found in linter repo check. Details: One or more screenshots are missing captions in the Metainfo file

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/233023/com.qq.QQ.flatpakref

Built for aarch64 and x86_64 architectures.

⚠️ Linter warnings:

Warnings can be promoted to errors in the future. Please try to resolve them.

• 'appstream-screenshot-missing-caption' warning found in linter repo check. Details: One or more screenshots are missing captions in the Metainfo file

[StarsEnd33A2D17]

A window titled “wl-clipboard” may appear unexpectedly, which can cause focus issues (see bugaevc/wl-clipboard#268).

for example, in niri v25.11, you need to add the following window-rule as a workaround:
It turns out that copying is not triggered when the window has no focus, so this workaround doesn’t work :(

window-rule {
    match title="wl-clipboard"
    open-focused false
    open-floating true
}

[Integral-Tech]

Unfortunately, QQ only supports x-special/gnome-copied-files MIME type for copied files:

proc = CompletedProcess(args=['xclip', '-selection', 'clipboard', '-out', '-target', 'TARGETS'], returncode=0, stdout='QQ_Unicode_RichEdit_Format\nx-special/gnome-copied-files\n', stderr='')

[arenekosreal]

Nesting xvfb, clipsync and zypak-wrapper together just for fixing QQ's misbehaving on Wayland, what a horrible thing I think. As for my personal opinion, I prefer doing what we have done in https://github.com/flathub/com.qq.QQ/blob/master/patch/rename.cpp, we inject something in QQ's native code to workaround this problem. But I do not do any research about it, hope we can find correct hook point if we have to do so.

If we need to inject Electron part, there has already been a tool: https://github.com/ShellWen/v8_killer

Using xvfb increases memory usage for about 40MB. It is acceptable here compared to QQ itself's memory usage.

P.S.: If we have no choice, current implementation is also acceptable.

[taoky]

As for my personal opinion, I prefer doing what we have done in https://github.com/flathub/com.qq.QQ/blob/master/patch/rename.cpp, we inject something in QQ's native code to workaround this problem.

I'm not going to do any reverse-engineering work, so anyone could submit a new PR if they are interested in and found this X11 function(s) to mock.

If we need to inject Electron part, there has already been a tool: https://github.com/ShellWen/v8_killer

I would be strongly against this approach as this is too invasive and could probably get user accounts banned.

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/240225/com.qq.QQ.flatpakref

Built for aarch64 and x86_64 architectures.

⚠️ Linter warnings:

Warnings can be promoted to errors in the future. Please try to resolve them.

• 'appstream-screenshot-missing-caption' warning found in linter repo check. Details: One or more screenshots are missing captions in the Metainfo file

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/253998/com.qq.QQ.flatpakref

Built for aarch64 and x86_64 architectures.

⚠️ Linter warnings:

Warnings can be promoted to errors in the future. Please try to resolve them.

• 'appstream-screenshot-missing-caption' warning found in linter repo check. Details: One or more screenshots are missing captions in the Metainfo file

[ihipop]

#218 (comment)
this trick works，without additional code
just disable fallback-x11，and keep x11/wayland， both window systemd works fine

[taoky]

#218 (comment) this trick works，without additional code just disable fallback-x11，and keep x11/wayland， both window systemd works fine

Enabling X and Wayland sockets at the same time is not recommended as it gives you a false sense of security -- applications still have the ability to do anything, including monitoring your mouse, keyboard, and getting your screen contents without consent, through X socket.

Also, the xvfb trick is not enabled when X socket is available:

com.qq.QQ/com.qq.QQ.yaml

Line 121 in 6d6349b

echo "X11 socket is not available, using Wayland + Xvfb..."

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/269597/com.qq.QQ.flatpakref

Built for aarch64 and x86_64 architectures.

⚠️ Linter warnings:

Warnings can be promoted to errors in the future. Please try to resolve them.

• 'appstream-screenshot-missing-caption' warning found in linter repo check. Details: One or more screenshots are missing captions in the Metainfo file

[ihipop]

#218 (comment) this trick works，without additional code just disable fallback-x11，and keep x11/wayland， both window systemd works fine

Enabling X and Wayland sockets at the same time is not recommended as it gives you a false sense of security -- applications still have the ability to do anything, including monitoring your mouse, keyboard, and getting your screen contents without consent, through X socket.

Also, the xvfb trick is not enabled when X socket is available:

I understand what you're worried about, but this isn't an issue of enabling both X and Wayland simultaneously. Because if we follow that logic—claiming that X programs pose significant security risks—then right now, no X program should exist. They should all be removed from Flathub, and Flatpak should drop support for X programs entirely.

In reality, the concerns you have can be completely avoided with proper configuration. In fact, KDE already offers a click-to-configure setting for key monitoring, making it even simpler.

It's a question of how far you want to go with this, not an issue of enabling the X server is something evil of source

[taoky]

if we follow that logic—claiming that X programs pose significant security risks

This is misinterpreted. Instead it should be -- untrusted programs, or programs that cannot handle untrusted contents securely, could pose significant security risks in sandboxed environment when exposed with X socket. And (unfortunately) QQ for many are just categorized as untrusted. It's much easier to just download the appimage from its website and use that if it's not the case.

In reality, the concerns you have can be completely avoided with proper configuration. In fact, KDE already offers a click-to-configure setting for key monitoring, making it even simpler.

Not everyone is a KDE user. Even if this is the case, not all security issues by Xwayland socket could be resolved. For example, QQ in recent versions could exhaust X connections in some cases, and this can be easily mitigated by disabling X socket in Flatpak.

[ihipop]

if we follow that logic—claiming that X programs pose significant security risks

This is misinterpreted. Instead it should be -- untrusted programs, or programs that cannot handle untrusted contents securely, could pose significant security risks in sandboxed environment when exposed with X socket. And (unfortunately) QQ for many are just categorized as untrusted. It's much easier to just download the appimage from its website and use that if it's not the case.

In reality, the concerns you have can be completely avoided with proper configuration. In fact, KDE already offers a click-to-configure setting for key monitoring, making it even simpler.

Not everyone is a KDE user. Even if this is the case, not all security issues by Xwayland socket could be resolved. For example, QQ in recent versions could exhaust X connections in some cases, and this can be easily mitigated by disabling X socket in Flatpak.

We both know that QQ's current Wayland support isn't actually intentional. It's only there because it uses Electron, which has its own built-in Wayland support, so the packagers forcefully enabled it. This is basically an accidental "security guarantee."

QQ itself is still writing to the X11 clipboard; logically, it has never even considered the Wayland environment. Therefore, treating it as an application that only supports X isn't really a major logical error.

Fundamentally, taking a program designed for X and slapping a bunch of patches on it to run on Wayland isn't essentially different from just running the program in a standalone Xwayland instance.

People who genuinely care about the keylogging issue will find ways to resolve it, even without that KDE setting.

As for the issue you mentioned about QQ exhausting X connections, that's fundamentally a problem with its software quality. But as I said, as long as one is willing to put in the effort, I could easily spin up a dedicated Xwayland service strictly for QQ. If you do that, the keyboard and screen monitoring issues you mentioned wouldn't be a problem at all. As I've said before, it's simply a matter of how far you want to go, not a question of whether or not to allowed to use X
or not。

I imagine that anyone willing to deal with Flatpak sandboxing already has some level of security awareness, which is exactly why they choose to run QQ via Flatpak in the first place. More advanced users might even write their own custom bwrap rules to run it. This is a completely separate issue from whether or not to simultaneously enable X and Wayland support for the Flatpak here.

I'm not dismissing your security concerns, but they shouldn't be based on the assumption that only Wayland equates to absolute security, nor should that be used as a reason to oppose enabling X support for an application inherently designed for X.

[taoky]

if we follow that logic—claiming that X programs pose significant security risks

This is misinterpreted. Instead it should be -- untrusted programs, or programs that cannot handle untrusted contents securely, could pose significant security risks in sandboxed environment when exposed with X socket. And (unfortunately) QQ for many are just categorized as untrusted. It's much easier to just download the appimage from its website and use that if it's not the case.

In reality, the concerns you have can be completely avoided with proper configuration. In fact, KDE already offers a click-to-configure setting for key monitoring, making it even simpler.

Not everyone is a KDE user. Even if this is the case, not all security issues by Xwayland socket could be resolved. For example, QQ in recent versions could exhaust X connections in some cases, and this can be easily mitigated by disabling X socket in Flatpak.

We both know that QQ's current Wayland support isn't actually intentional. It's only there because it uses Electron, which has its own built-in Wayland support, so the packagers forcefully enabled it. This is basically an accidental "security guarantee."

QQ itself is still writing to the X11 clipboard; logically, it has never even considered the Wayland environment. Therefore, treating it as an application that only supports X isn't really a major logical error.

Fundamentally, taking a program designed for X and slapping a bunch of patches on it to run on Wayland isn't essentially different from just running the program in a standalone Xwayland instance.

People who genuinely care about the keylogging issue will find ways to resolve it, even without that KDE setting.

As for the issue you mentioned about QQ exhausting X connections, that's fundamentally a problem with its software quality. But as I said, as long as one is willing to put in the effort, I could easily spin up a dedicated Xwayland service strictly for QQ. If you do that, the keyboard and screen monitoring issues you mentioned wouldn't be a problem at all. As I've said before, it's simply a matter of how far you want to go, not a question of whether or not to allowed to use X or not。

I imagine that anyone willing to deal with Flatpak sandboxing already has some level of security awareness, which is exactly why they choose to run QQ via Flatpak in the first place. More advanced users might even write their own custom bwrap rules to run it. This is a completely separate issue from whether or not to simultaneously enable X and Wayland support for the Flatpak here.

I'm not dismissing your security concerns, but they shouldn't be based on the assumption that only Wayland equates to absolute security, nor should that be used as a reason to oppose enabling X support for an application inherently designed for X.

You take your own responsibility for your own device, thus if you fully understand the risk, you can just enable that on your computer and nobody would stop you from doing so. My PR with xvfb before also considers this case and it works.

So I believe that what we argue is: How shall flatpak packagers set the default sandboxing values for their users, especially for untrusted (close-source) apps or apps with a bad security record? Two approaches here:

• Set secure arguments by default, at the sacrifice of some functionalities not working.
• Make sure all functionalities work, at the sacrifice of leaving some security holes in the sandbox.

Both approaches have their reasons, and that's OK for me. For the case of X-Wayland issue you mentioned, the approaches should be:

• Only set Wayland & fallback-x11 (make sure it does not have access to Xwayland socket in Wayland environment, with most functionalities work).
• Or, only set X11 sockets (as it is only tested by its developers in X11 environment).

Settings both Wayland & X11 sockets enabled by default does not make any sense, and it's not responsible to do so. For power users they can just:

• Use the build in this PR (it works nicely on my computers, and it's not difficult to test or build locally).
• Enable Wayland & X11 sockets together.
• Disable Wayland socket and enable X11 socket.

Though I believe that some documentation work (mentioning the clipboard issue in README and providing some workarounds) could be done here to improve UX.

[ihipop]

You make a fair point; I'm simply arguing about what makes for a more reasonable default. Meanwhile, you keep using X's security flaws to try to prove that X shouldn't be used at all (even though those flaws are real).

​As I mentioned earlier, QQ is fundamentally an application designed for X. The packagers forced some of its modules to run under Wayland, yet other parts still operate based on X11 logic. Consequently, its default operational state is inherently fragmented.

Given this, it's perfectly reasonable for the container to enable both X and Wayland support simultaneously—it aligns with the app's actual working state. This is also the current default, which guarantees it works out of the box. You can't use 'X11 is insecure' as an excuse not to enable X support for an X-based program (otherwise, Flatpak shouldn't offer X11 support at all, given that its core feature is sandboxed permission restrictions designed precisely for insecure apps). Doing so isn't 'irresponsible'; it merely reflects the reality of how the application currently functions.

​The current reality is that the X11 fallback is also enabled by default, which creates a very disjointed setup. Exactly as you pointed out, users have no way of knowing right off the bat why their clipboard isn't working. What they need is proper documentation guiding them on how to configure things

[taoky]

Given this, it's perfectly reasonable for the container to enable both X and Wayland support simultaneously—it aligns with the app's actual working state. This is also the current default, which guarantees it works out of the box. You can't use 'X11 is insecure' as an excuse not to enable X support for an X-based program (otherwise, Flatpak shouldn't offer X11 support at all, given that its core feature is sandboxed permission restrictions designed precisely for insecure apps). Doing so isn't 'irresponsible'; it merely reflects the reality of how the application currently functions.

​The current reality is that the X11 fallback is also enabled by default, which creates a very disjointed setup. Exactly as you pointed out, users have no way of knowing right off the bat why their clipboard isn't working. What they need is proper documentation guiding them on how to configure things

Unfortunately you are making conflicted arguments:

QQ itself is still writing to the X11 clipboard; logically, it has never even considered the Wayland environment.

it's perfectly reasonable for the container to enable both X and Wayland support simultaneously—it aligns with the app's actual working state.

If you're going approach 2, it does not make any sense to open Wayland socket, if an application is only considered to be run in X11 environment. This adheres Principle of Least Privilege.

You can't use 'X11 is insecure' as an excuse not to enable X support for an X-based program

I have never said that.

Flatpak shouldn't offer X11 support at all

IMHO it's a compromise for real-world engineering, and in a perfect world X shall be deprecated and no longer used.

The current reality is that the X11 fallback is also enabled by default, which creates a very disjointed setup.

It looks like you fail to get what socket=fallback-x11 actually do.

---

I believe that I have clearly state my opinions in #225 (comment), and continuing on this topic is no longer constructive. So I would ignore your further comments on this specific topic, and just let the maintainer of the package to do the final decision.