Manage Deluge as PMSS-controlled install — upgrade to 2.2.0+ for security fixes

[MagnaCapax]

Summary

Transition Deluge from an apt/pip-installed package to a fully PMSS-managed install with version pinning, following the same pattern used for rtorrent. The immediate driver is Deluge 2.2.0 which fixes critical security vulnerabilities that Debian repos will not ship in time.

Current State

Debian 10 (buster): Deluge 2.0.5 installed from source tarball via pip + python3 setup.py install (global, no virtualenv). Tarball is fetched from ftp.osuosl.org with SHA256 verification. Python dependencies installed system-wide via pip install --upgrade. See scripts/lib/update/apps/deluge.php lines 32-91.

Debian 11/12 (bullseye/bookworm): Deluge installed via apt-get install -y deluged deluge-web. The apt check is idempotent (skips if already installed). Debian 12 ships Deluge 2.0.5 or 2.1.1 depending on the repo. See scripts/lib/update/apps/deluge.php lines 93-104.

No upgrade path exists. Once installed, PMSS never upgrades Deluge beyond what was initially installed. There is no version comparison or upgrade logic for the apt path -- it only checks "is the package installed?" and skips if yes.

Security Motivation

CVE-2025-46564 (Critical): Unauthenticated path traversal in Deluge web UI /js endpoint allows reading arbitrary OS files -- including the plaintext auth file containing daemon passwords. No authentication required. Fixed in Deluge 2.2.0.

Plaintext auth (all versions <= 2.1.1): Deluge daemon auth file stores passwords in plaintext. Deluge 2.2.0 adds scrypt hashing for non-localclient accounts. Combined with CVE-2025-46564, this means an unauthenticated attacker can read daemon credentials from any pre-2.2.0 Deluge instance.

CVE-2017-7178 (High): CSRF leading to malicious plugin upload and RCE. Still exploitable on authenticated instances.

These are not theoretical -- Deluge instances with default/weak passwords are actively exploited for cryptomining in the wild. PMSS runs Deluge facing the internet with per-user daemon ports.

Proposed Approach

Follow the rtorrent model (scripts/lib/update/apps/rtorrent.php):

1. Version-pinned source install via pip (PyPI) -- pip install deluge==2.2.0 in a virtualenv or system-wide with explicit pinning
2. SHA256 verification of downloaded packages (pip supports --require-hashes)
3. Version detection -- compare running version against target, only upgrade when needed (idempotent)
4. Symlinks to /usr/local/bin/ for deluged and deluge-web (existing pattern, see lines 108-113)
5. Kill + restart cycle -- after upgrade, kill all running Deluge instances; cron watchdog (checkDelugeInstances.php) will restart them automatically
6. Template update -- update any Deluge config templates if the new version requires format changes

Alternative: pip install from PyPI

Unlike rtorrent (C++, compiled from source), Deluge is pure Python. The most natural install path is:

pip3 install --upgrade deluge==2.2.0 --require-hashes

This avoids the complexity of compiling from source while still giving full version control. A virtualenv approach (as suggested in GH#125) would be even cleaner but requires updating all paths in cron scripts and user-facing tools.

Dependencies to Investigate

• Python 3 version: Deluge 2.2.0 requires Python >= 3.7. Debian 10 ships Python 3.7.3 (should work). Verify.
• libtorrent-rasterbar: Deluge uses libtorrent (the Rasterbar library, NOT the rtorrent one). Debian 10 ships 1.1.x, Debian 12 ships 2.0.x. Check Deluge 2.2.0 minimum requirements.
• Twisted: Deluge depends on Twisted[tls]. The current Debian 10 installer already installs this via pip.
• GObject Introspection: deluge-web needs python3-gi and related packages from apt (these cannot be pip-installed).

Risks and Mitigations

Risk	Mitigation
Deluge 2.2.0 requires newer Python than Debian 10 provides	Test on Debian 10 first; if incompatible, pin 2.1.1 for Debian 10 and 2.2.0 for Debian 11+
libtorrent-rasterbar version mismatch	Check Deluge 2.2.0 release notes for minimum libtorrent version
Config format changes between versions	Test upgrade path with existing user configs before fleet rollout
Breaking changes in Deluge 2.2.0 auth	scrypt auth for non-localclient accounts -- existing plaintext auth files will be upgraded on first daemon start (verify this behavior)
pip install conflicts with apt packages	Remove apt packages first if present, or use --force-reinstall

Files Affected

• scripts/lib/update/apps/deluge.php -- main installer, needs rewrite for managed approach
• scripts/lib/user/deluge.php -- user config provisioning (may need auth template updates for scrypt)
• scripts/cron/checkDelugeInstances.php -- watchdog (binary paths may change)
• scripts/lib/user/passwords.php -- Deluge password handling (GH#211 interaction)
• etc/seedbox/config/template.deluge.* -- config templates (format changes?)
• scripts/lib/lighttpd/delugeWebConf.php -- web config parser (Deluge 2.2.0 may change web.conf format)

Relationship to Existing Issues

• GH#125: "Converge Deluge installer to dpkg baselines or pinned virtualenv" -- this issue supersedes Deluge: converge installer to dpkg baselines or pinned virtualenv (no global pip, logged steps) #125 by going further: not just converging the installer, but taking full version control for security reasons
• GH#207: "Add ltconfig plugin and update to current version" -- version update component is subsumed by this issue; ltconfig integration should be done as part of the managed install
• GH#211: "Generate separate random password instead of syncing account password" -- the auth changes in Deluge 2.2.0 (scrypt hashing) directly interact with Deluge: generate separate random password instead of syncing account password #211's implementation
• GH#212: "Add security doctrine to AGENTS.md" -- this issue is a concrete example of why security doctrine matters; the managed install addresses the CVE exposure gap

Acceptance Criteria

• Deluge 2.2.0+ installed on all supported Debian versions (10, 11, 12)
• Version pinned with explicit version target per Debian release
• SHA256 or hash verification on all downloaded packages
• Idempotent: running update.php twice does not reinstall if already at target version
• Existing user configs preserved and functional after upgrade
• Deluge auth file format handled correctly (plaintext -> scrypt transition)
• Watchdog cron (checkDelugeInstances.php) works with new binary paths
• deluged --version reports expected version after install
• CVE-2025-46564 is confirmed not exploitable on 2.2.0

---

— Vainamoinen

[MagnaCapax]

QA Verification: PASS

Commit verified: 5545b4c

Layers Tested

L1 Structural: php -l clean on deluge.php.

L2 Happy Path: Changed apt install logic from "skip if installed" to "always run apt-get install -y". Since apt is idempotent, this is a no-op when packages are already at latest version, but correctly upgrades when a newer version is available after a Debian major version upgrade (11 → 12 → 13).

L3 Adversarial: The old code path (echo "*** Deluge packages already installed; skipping") silently prevented security updates and version upgrades. The fix ensures apt always runs, catching both.

L4 Red Team: Dynamic step label ('Upgrading Deluge packages' vs 'Installing Deluge packages') provides clear logging. systemctl disable deluged runs unconditionally (PMSS manages Deluge per-user, not via systemd).

Caveat

This commit fixes the upgrade-awareness gap. The broader #213 scope (version pinning, SHA256, CVE-2025-46564 fix, Deluge 2.2.0) is not yet implemented.

• Test: PASS