Skip to content

Security: s3rven/silere-shell

Security

SECURITY.md

Security

Reporting

Report a vulnerability privately through GitHub Security Advisories. Please don't open a public issue for anything exploitable.

Expect a first reply within a week. Fixes ship in the next patch release, credited unless you'd rather not be.

Scope

Silere runs as the user's own session, with their permissions. It has no daemon, no network listener, and no privileged helper. What's in scope:

  • Notification content reaching the shell over D-Bus, including icon and image paths.
  • Anything the shell passes to a process it spawns.
  • Files the shell reads or writes under $XDG_CONFIG_HOME, $XDG_STATE_HOME and $XDG_CACHE_HOME, and the ~/.local paths the installer creates (the silere command and the bundled font).
  • The installer and updater scripts under scripts/.

Out of scope: Quickshell, the compositor, and anything requiring an attacker who already runs code as the user.

Notification icons and images accept Quickshell's in-memory image provider, icon names from the installed icon theme, and files inside the system icon directories, which only root can write to. Any other filesystem path supplied by the sender is refused.

Update trust

Updates are verified: scripts/update.sh fast-forwards to an annotated tag signed by a key in security/update-signers, using the copy of that key already in the installed checkout, and only when the tag belongs to origin/main. Rolling back a completed update (--rollback) and recovering an interrupted one also reset to a revision the signed transaction journal names. After signature verification and confirmation, the update gate runs the candidate release's QML checker and starts its shell in smoke mode before switching revisions.

Remote cover art is optional. Enabling it sends requests to image hosts named by players, which can reveal what you are playing; Qt's remote image loading has also caused a shell crash on some systems.

The first install is a different matter. git clone followed by scripts/install.sh runs code from main before any signature has been checked, and a repository that shipped a tampered install.sh would also ship a tampered signer list. Nothing inside the repository can close that gap — verifying a clone needs a trust anchor obtained separately from it. Treat the initial clone as the point where you decide to trust the source, and prefer a distribution package where one is available.

There aren't any published security advisories