Would it be feasible to emit Workspace::clientAdded for Wayland clients as well?

The main reason for not exposing Wayland clients to scripting was that this violates the Wayland security model. Through scripting api the complete windowing system is open again.

I wanted to keep Wayland windows out of scripting till we have secured the API (e.g. dedicated permissions for accessing dbus).

In D17097#364318, @graesslin wrote:

(e.g. dedicated permissions for accessing dbus).

So, it would be something similar to what web browsers have when it comes to extensions(e.g. "Access your data for all websites", "Read and modify privacy settings", etc)?

better not doing now something now that has design problems and will be hard to retract..

In D17097#364320, @zzag wrote:

In D17097#364318, @graesslin wrote:

(e.g. dedicated permissions for accessing dbus).

So, it would be something similar to what web browsers have when it comes to extensions(e.g. "Access your data for all websites", "Read and modify privacy settings", etc)?

That would be a possible idea on how one could implement it. I could think of metadata defines what extensions it uses (e.g. dbus, global shortcut, read settings, screenedge, etc...) and on first load the user needs to ack these settings. For a not acked setting the calls would just not work.

The problem with the approach is that we cannot secure the kwinrc to which it is written. So the whole thing doesn't really work as long as all processes can write kwinrc. On the other hand it could protect properly sandboxed flatpacks.

Btw. I don't think we need to discard the reviews. I could also see a solution in disabling the dbus extension on Wayland or to say we ignore the security problems due to the point written above.

In D17097#366223, @zzag wrote:

In D17097#365086, @graesslin wrote:

The problem with the approach is that we cannot secure the kwinrc to which it is written. So the whole thing doesn't really work as long as all processes can write kwinrc. On the other hand it could protect properly sandboxed flatpacks.

Could we use kwallet for such a purpose? Also, do web browsers try to secure the list of enabled extensions?

KWallet is not secure at all. I don't know how browsers handle this.

KWallet is not secure at all.

Kwallet is secure at its one job. Keeping passwords secret if your harddrive is stolen and mounted in another machine.

The problem with kwallet is it gained the nonsense "access control" where it pretends it's doing something that it can't do.

or to say we ignore the security problems due to the point written above.

IMHO yes.

Wayland (display sandboxing) and the filesystem sandboxing are two parts of securing a system and either one is useless without the other.

If a process can read/write to all your files you've already lost.
Even if we did secure kwin somehow magically, I'm not securing the .desktop files plasma loads and there's a million other vectors.

We should have prompts and permissions for scripts off the internet (though that's unrelated to this patch), but IMHO trying to protect Kwin/Plasma from unsandboxed processes running as the same user meddling with the config should IMHO be declared out of scope and we should be up front about it.

Given wayland clients are already exposed with a slightly more obscure API already. I think shipping this as-is now totally makes sense, but I don't want to go against Martin F.

I'm just commenting on this as a user not a developer, however the only thing stopping me from switching to Wayland is the lack of the tiling extension.

I understand the reservations from a development point of view but as a user it's frustrating watching this sit here. Would it be possible to either:

• Add a config option somewhere that enables this functionality (I'm happy editing a file rather than requiring a GUI option)
• A warning when adding a script that says something about not trusting random scripts from the internet

As is stands, this prevents even the most basic example from the scripting manual page from working as documented. From https://techbase.kde.org/Development/Tutorials/KWin/Scripting :

var clients = workspace.clientList(); 
for (var i=0; i<clients.length; i++) {
  print(clients[i].caption);
}

• Add a config option somewhere that enables this functionality (I'm happy editing a file rather than requiring a GUI option)
• A warning when adding a script that says something about not trusting random scripts from the internet

Neither of the above would solve the issue.

• The configuration options are stored in plaintext and are writable by any process.
• The scripting interface is exposed on D-Bus, so any process can download and run any arbitrary script.

The solution would be to store the plugins configuration encrypted (or in general to allow for encrypted config sections) and to remove potentially dangerous methods from the D-Bus interface.

I do, however agree, that the scripting interface is currently virtually unusable on Wayland.

The solution would be to store the plugins configuration encrypted (or in general to allow for encrypted config sections)

Perhaps neither that would help. A rogue app could inject malicious code into the script or completely replace it with something else.

and to remove potentially dangerous methods from the D-Bus interface.

The only way to make the D-Bus interface safe is to remove it.

The only way to make the D-Bus interface safe is to remove it.

Please don't. It's a non issue.
Any sandboxing tech will have blocked off unrestricted DBus session bus access already.

or to say we ignore the security problems due to the point written above.

Martin said this, I fully agree, he hasn't responded in a while.

I say ship it. Especially given it doesn't expose anything that isn't implicitly available anyway

A rogue app could inject malicious code into the script or completely replace it with something else.

Assuming we have an encrypted config section, we can of course store script fingerprint there.

I say ship it. Especially given it doesn't expose anything that isn't implicitly available anyway

Couldn't agree more.

When is this likely to appear in a release? I just tried 5.16.90 (5.17 beta) and the following script still doesn't contain Wayland windows.

var clients = workspace.clientList(); 
for (var i=0; i<clients.length; i++) {
  print(clients[i].caption);
}

How do you test that script?