Looks only change settings. They can't run programs on your computer.

That sentence appears on the app's own welcome screen, and it is a property of the design rather than a policy someone has to remember.

A Look is a folder containing pictures and one text file. The text file lists settings to change and files to copy. There is no section in the format for running a command, and there is no code anywhere in gtheme that could run one:

• the format is defined by strict models that reject any field they do not recognise, so a Look with a [[hooks]] section — the section version 1 of this project had, which really did run scripts — fails to load rather than being ignored;
• the layer that applies changes understands exactly four kinds of operation: write a file, write a setting, switch an add-on on, install an add-on. There is no fifth;
• version 1 Looks are converted, not accepted. The converter drops each script and prints a warning naming what that script used to do. Nothing survives the conversion silently.

This is a direct answer to a real incident elsewhere: a downloadable "global theme" for another Linux desktop ran a delete command and wiped users' mounted drives, because on that desktop a theme can contain executable code. Here it cannot.

A Look can copy files into your home folder and change your desktop's settings. Two boundaries constrain that, and both are checked before the first byte is written, not as it goes:

Where files may land. Every destination is resolved — following .. and following symbolic links — and must come out below your home folder. A Look asking to write to ~/../../etc/sudoers, or shipping a link that points outside its own folder, is refused. The whole operation is refused, before anything has happened, rather than partway through.

Where files may come from. Sources are resolved the same way and must stay inside the Look's own folder, so a Look cannot use a symbolic link as a siphon to copy your private keys out into somewhere it can publish them.

Everything is recorded first. Before gtheme changes anything, it records what was there. Any Look can be completely undone, including one that turns out to be malicious rather than merely ugly.

Nothing is silently overwritten through a link. If the place a file would land is a symbolic link into some other project, gtheme replaces the link rather than writing through it — and for the specific case of a settings folder managed by another tool, it refuses to write at all until you say otherwise.

Add-ons (GNOME calls them extensions) are third-party code that your desktop loads and runs. That is what they are for; it is also what makes them the riskiest thing gtheme can help you install, and no amount of care on our side changes that.

What gtheme does about it:

• Installing goes through GNOME's own confirmation box. gtheme asks the desktop to install an add-on; the desktop shows you its own dialog, naming the add-on, and you approve it there. gtheme cannot install one behind that.
• A Look never carries add-on code. It can name an add-on it would like, and gtheme offers to fetch that add-on from extensions.gnome.org — the same place GNOME's own website installs from. A Look that names a private add-on you do not have is applied without it, and says which part will therefore not work.
• gtheme remembers which add-ons it switched on, so gtheme rescue can switch exactly those back off from a text console when the desktop itself is unusable.

Nothing, unless you ask, and then only these two:

There is no account, no server run by this project, no telemetry, no crash reporting, and no identifier of any kind attached to those two requests.

When you publish a Look of your own, gtheme scans what it captured for things you would not want to share — your username inside a file location, tokens or keys some add-on stored in its settings — and shows you what it found before you send it anywhere.

gtheme runs entirely as you. It never asks for administrator rights, and nothing it does needs them.

Please report privately first.

Use GitHub's private vulnerability reporting: go to https://github.com/blyatiful1/gtheme/security/advisories/new — or the Security tab of the project page on GitHub, then Report a vulnerability. That creates a report only the maintainers can see.

If that page is unavailable to you, open a normal issue at https://github.com/blyatiful1/gtheme/issues saying only that you have a security report and asking for a private channel. Do not put the details in a public issue.

Please include, as far as you can: what you did, what happened, what you expected, your distro and GNOME version, and whether a Look, an add-on or the app itself was involved.

What to expect. This is a small project maintained by one person, so the honest answer is that there is no guaranteed response time. Reports are read. Anything that lets a Look escape the two boundaries above, or that gets code running from something a user believed was decoration, is treated as the most serious class of bug there is here and takes priority over everything else.

In scope: gtheme itself, the Look format, the change-applying layer, the community list of Looks, and anything shipped with this project.

Out of scope: the behaviour of individual add-ons published on extensions.gnome.org (report those to their authors and to GNOME), and bugs in GNOME itself or in your distro. If gtheme presents one of those unsafely — makes something dangerous look routine — that part is in scope, and worth telling us about.

Version 2 is the only line receiving fixes. Version 1 is preserved on the legacy-v1 branch for people who still depend on it, but it is not maintained, and it is the version that could run scripts.