WebCord icon indicating copy to clipboard operation
WebCord copied to clipboard

Add a way to add CSS themes that doesn't require GUI

Open the-argus opened this issue 1 year ago • 2 comments

Is your feature request related to a problem? Please describe. I use NixOS, and I used to manage a very nice systemwide color palette which could be swapped out on a whim. This is now broken after the addition of --add-css-theme, which requires manual user interaction with a dialog window for theme change.

Describe the solution you'd like Add a --no-start or --no-gui cli flag, such that the typical dialog window could instead be a simple print statement. This would enable declarative installation of themes on my end by installing them and then running webcord --no-gui --add-css-theme=path/to/theme

EDIT: it should probably just be called --confirm-all or something, so the dialogue box is bypassed.

Describe alternatives you've considered Remove the --add-css-theme flag entirely. I'm not sure what security hole you're really patching here: if another application can be exploited to write malicious themes to ~/.config/Webcord/Themes, then that's a hole in another application and should be addressed there. Additionally, you could remove the flag and instead add a dialogue to any startup where a new theme is detected in the themes folder.

I am willing to implement this feature provided it is welcome.

the-argus avatar Sep 09 '22 14:09 the-argus

The dialog is actually there for a reason – I assume it is hard for thirdparties to inject the CSS themes (and in the future - also modify CSP) when a GUI popup is present. The way it works is meant to prevent other software that can have access to the entire filesystem (limited by user permissions) from any kind of the manipulation outside of WebCord.

I'm not sure what security hole you're really patching here: if another application can be exploited to write malicious themes to ~/.config/Webcord/Themes, then that's a hole in another application and should be addressed there.

Files loaded there are encrypted with the key stored in the secret service, so there should be no way for that software to actually inject their own scripts unless they guess the key. That being said, the code is still at initial state and I haven't really tested how it works with the plaintext (and if it can be abused), but definitely will do before WebCord will modify CSP based on themes. This update was more like a preparation, the --add-css-theme might be deprecated in the future in favor of the GUI configuration.

As of the details, it uses the same mechanism as in Chromium for encrypting the passwords. WebCord will also not encrypt anything when the secret service is unavailable (on Freedesktop-compilant operating systems, like FreeBSD or Linux).

(…) then that's a hole in another application and should be addressed there.

This mechanism is not just to prevent the issues with another software's security, but also mitigate the consequences of installed software that is being malicious by the design. But it's future-proof solution, making the most sense when WebCord will allow tweaking the CSP. I also plan to partially encrypt the configuration files: one of my ideas is to split it to earlyConfig (unencrypted, pre-Electron configuration, mostly for Node tweaks and Chromium flags modifications) and lateConfig (encrypted, loaded after Chromium engine is being initialized).


So, what's my idea about these dialogs? I could allow to disable them using the configuration... which itself is unencrypted, so that is something I would have to work on first. I don't like the idea of CLI or TUI, stdin can be easily manipulated.

SpacingBat3 avatar Sep 09 '22 14:09 SpacingBat3

Alright, I'll leave this issue open if you plan on providing a solution at some point, but I won't make a PR.

the-argus avatar Sep 10 '22 14:09 the-argus