sctg-development/sctgdesk-server sctg-v1.1.16-sctg.5

SCTGDesk server 1.1.16-sctg.5

on GitHub

SCTGDesk server 1.1.16-sctg.5

Clearer login errors, a generated cookie key, health probes, and an overhaul of the dependencies (30 security advisories down to 4, each explained). The client moves to upstream RustDesk 1.5.3. Based on upstream rustdesk-server 1.1.16, like the previous releases.

SCTGDesk is an independent project, not affiliated with or endorsed by the RustDesk project or Purslane Ltd. Licensed under the AGPL-3.0; the source of this release is this repository at the tag sctg-v1.1.16-sctg.5.

Server

• A failed login answers a JSON error ({"error":"Wrong username or password"}) instead of an empty 401, which the clients fail to read ("Unexpected end of input"). Idea taken from forks of this repository.
• The cookie key is no longer the same on every installation. The Rocket secret_key was one constant in the source. It now comes from ROCKET_SECRET_KEY, or from secret_key.txt next to the database, created with a random key at the first start (mode 600). Back it up with the key pair.
• Health probes. hbbs answers GET /livez and GET /readyz (200 when the database answers, 503 otherwise) on the API port; hbbr does it on HEALTH_PORT, off unless set. The Helm chart can enable them (probes.enabled, off by default). See the deployment guide.

Dependencies and security

cargo audit reported 30 vulnerabilities; the build now has 4, each listed with its reason in .cargo/audit.toml, and the audit is blocking in the CI.

• sqlx 0.9, Rocket without HTTP/2 (it pulled an h2 without fix), the AWS SDK without its legacy TLS stack, and updated rustls, zstd, crossbeam, tracing-subscriber, idna.
• Left: crypto-bigint, users and webpki-roots come from the hbb_common submodule (upstream RustDesk, kept as it is), and libsqlite3-sys is capped by sqlx (local attack with crafted database files).

Client

• The client overlay is rebuilt on upstream RustDesk 1.5.3, and the Apple Silicon client is built with Flutter 3.44.9, as upstream does. The update check follows the new upstream flow and sends users to the download of their platform.

Upgrading

Back up db_v2.sqlite3, your key pair and, after the first start, secret_key.txt. No configuration change and no migration. The cookies of the web console are invalidated once, at the first start. Rolling back the binary is enough.

Known limitations

• The 1.5.3 clients (Windows, macOS) build in the CI, but have had little testing beyond that: report any problem.
• Not tried with the official clients: the filters of the "accessible" tabs, the 403 answers and the end-of-connection note dialog (1.1.16-sctg.4).
• The S3 upload path of the software update service was moved to another HTTPS client; its tests against a live bucket were not run.
• The records posted by the devices cannot be authenticated; the web client does not send audit events; currentUser reports is_admin while the clients read admin.
• The Windows and macOS server binaries are not signed; no iOS, Android or Linux client build.