TS Pro Backup v1.3.1

TS Pro Backup v1.3.1

Maintenance release. The project has moved to a new home under the
hyprlab account on both GitHub and Docker Hub. There are no code or
behaviour changes — this release only updates the repository and image
coordinates.

What changed

• Source now lives at
  hyprlab/tspro-backup.
• The published image is now
  hyprlab/tspro-backup.

How to upgrade

Point your docker-compose.yml at the new image and pull:

    image: hyprlab/tspro-backup:latest

docker compose pull && docker compose up -d

License

AGPL-3.0-or-later.

v1.3.0 — Remote restore

TS Pro Backup v1.3.0

New feature: remote restore. You can now push a stored backup from this
console straight back into the live TS Pro site it came from — for the day the
site's data gets corrupted, or its admin can't log in.

What's new

Until now, recovery was one-directional and manual: you'd download a backup,
decrypt it, and re-import it from inside the site — useless precisely when
the site is broken or you're locked out of it.

Remote restore flips that around. From a connected site's full backups,
click Remote restore, paste the site's private key, and confirm. This
server pushes the archive to the site, which decrypts and applies it — no admin
login on the site required. It's out-of-band disaster recovery driven entirely
from here.

The site keeps a timestamped copy of its old data before overwriting, and
clears its own login lockouts so you can sign back in afterwards.

How to turn it on

It's off until each site opts in — a destructive recovery path shouldn't be
enabled silently:

1. Upgrade the connected site to TS Pro 2.11.0 or later.
2. On that site: Settings → Off-site backups → the target for this server →
   tick "Allow remote restore", set the portal's public URL, and save / test.
3. It registers here automatically. This server's site page then shows it as
   paired, and full backups gain a Remote restore action.

Security

Two independent secrets gate every restore, so neither alone is enough:

• a shared token the site publishes here (authenticates the push), and
• the operator's private key, supplied at restore time, which the site
  uses to decrypt the archive and to confirm it matches the key on file.

A stolen token alone can't push a malicious archive. This server stays
zero-knowledge — it only forwards ciphertext; the private key passes through
in memory and is never stored.

Who should upgrade

Everyone, when convenient — the upgrade is safe and automatic, and remote
restore stays dormant until you enable it per site.

docker compose pull && docker compose up -d

License

AGPL-3.0-or-later.

TS Pro Backup v1.2.1 — fix HTTPS login regression

TS Pro Backup v1.2.1

Hotfix. Fixes a regression that broke console sign-in over HTTPS.

The bug

On a TLS deployment (the recommended production setup), logging in — and every
other console form — failed with:

400 Bad Request
The referrer header is missing.

The Referrer-Policy: no-referrer header added in 1.1.0 told browsers never to
send the Referer header, but Flask-WTF's CSRF protection performs a strict
referrer check over HTTPS and rejects a form POST whose Referer is missing.

The fix

The policy is now Referrer-Policy: same-origin: the Referer is sent on
same-origin requests (so CSRF passes) and still withheld from external sites.

Who should upgrade

Anyone running 1.1.0 or 1.2.0 behind HTTPS — sign-in is broken on those
versions. Upgrade with:

docker compose pull && docker compose up -d

No data or configuration changes.

License

AGPL-3.0-or-later.

TS Pro Backup v1.2.0 — privilege separation + hardening

TS Pro Backup v1.2.0

A follow-up hardening release that finishes the privilege-separation work
from the security review and adds a few more defence-in-depth layers.
Upgrading is safe and automatic.

Highlights

• 👥 The user role is now genuinely limited. Non-admin operators can
  manage sites and backups (create/edit a site's name + retention, browse and
  delete backups) but can no longer rotate a site's API key or encryption
  keypair, delete a site, or change a site's encryption policy. Those actions
  are admin-only — enforced on the server and hidden in the console for
  non-admins.
• 🧩 Content-Security-Policy on the console: scripts are restricted to
  same-origin plus the (optional) Cloudflare Turnstile widget, framing is
  forbidden (clickjacking), and forms can only post back to the app.
• 📁 Transient files stay on the data volume. Upload staging and at-rest
  decrypt temp files now live under <DATA_DIR>/tmp (owner-only) instead of
  shared /tmp — so any transient plaintext is on the controlled volume and
  disk usage is accounted honestly.
• ⚙️ Threaded workers. gunicorn now runs gthread workers, so a couple of
  slow multi-GB transfers can't pin every worker and stall the console.
• 🩹 De-versioned the dev-server Server banner.

No new configuration is required, and no environment variables changed.

Install

docker pull viibeware/tspro-backup:1.2.0

Or with Docker Compose — see the README.

Upgrading

docker compose pull && docker compose up -d

Your ./data volume is preserved. One thing to know: if you have non-admin
(user) operators, they will lose access to key rotation, site deletion, and
per-site encryption-policy controls — these are now admin-only by design. Make
sure at least one admin account exists for those tasks (there always is —
the seed account is an admin).

License

AGPL-3.0-or-later.

TS Pro Backup v1.1.0 — security hardening

TS Pro Backup v1.1.0

A security-hardening release.

After a full security review of the whole app, this release adds brute-force
protection to the console login and closes a range of authentication,
encryption-integrity, and denial-of-service gaps. Upgrading is safe and
automatic — see the one-time effects under Upgrading.

Highlights

• 🔒 Login lockout. Failed console sign-ins are now rate-limited with a
  sliding window (per username and per IP) that survives restarts and
  multiple workers — so the operator password can't be brute-forced. Tunable
  via TSPB_LOGIN_MAX_FAILURES / TSPB_LOGIN_WINDOW_MINUTES.
• 🪪 Forced first-login password change. Any account still on the default
  admin password is walked through a one-time change wizard before anything
  else is reachable — no more standing admin/admin.
• 🔑 No usable default signing key. With TSPB_SECRET_KEY unset, the
  server now generates and persists a random key instead of a shipped
  constant, closing an admin-session-forgery path on non-compose deployments.
  Changing a password also invalidates that account's other sessions.
• 🧬 Stronger E2EE gate. The upload gate validates the full TSPEPK01
  envelope structure (not just an 8-byte magic prefix), rejects E2EE-required
  uploads from keyless sites, and records the recipient-key fingerprint per
  backup. The zero-knowledge guarantee is now described honestly: the server
  validates format, because it holds no private key to verify ciphertext.
• 🧱 Upload DoS caps. Chunked uploads enforce per-chunk, total-count,
  cumulative-size, and free-disk limits, with an optional per-site quota
  (TSPB_SITE_QUOTA_MB); total_chunks is mandatory and chunks must be
  contiguous, so a partial upload can't become a silently truncated backup.
• 🛡️ Hardened runtime. The container runs as a non-root user; responses
  carry X-Frame-Options / X-Content-Type-Options / Referrer-Policy /
  HSTS; remember-me cookies get the same flags as the session cookie; the DB
  and blobs are 0600; /logout is POST-only; and the Werkzeug debugger is
  split onto its own TSPB_FLASK_DEBUG flag.
• ⬆️ Dependencies. Werkzeug → 3.0.6 (CVE-2024-49767), requests → 2.32.4.
• 🐞 Fixed a fresh-boot crash race (two workers seeding the database at
  once) and enabled SQLite foreign-key cascade so deleting a site cleans up
  its backups instead of orphaning them.

Install

docker pull viibeware/tspro-backup:1.1.0

Or with Docker Compose — see the README.

Upgrading

docker compose pull && docker compose up -d

Your ./data volume is preserved and schema changes apply automatically.
Three one-time effects:

1. All current console sessions are invalidated once (the session-token
   format changed) — just sign in again.
2. Any admin still using the admin password is sent through the forced
   change wizard on next sign-in.
3. A site that has E2EE required but no encryption key must have its
   keypair rotated in the console before it can accept uploads again.

If your container port is reachable directly (not solely through a trusted
reverse proxy that overwrites X-Forwarded-For), set TSPB_TRUST_PROXY=0 so
the login lockout keys on the real client IP.

⚠️ Keep your keys

Two secrets, lost, mean permanently unrecoverable backups — by design:
the per-site private key, and the at-rest passphrase / data/rest.key
if you rely on encryption at rest. This server keeps a copy of neither.

License

AGPL-3.0-or-later.

v1.0.2

Adaptive, mobile-responsive site-credentials modal.

Changed

• Fits any viewport height. The one-time credentials reveal now has a fixed header and footer with an internally-scrolling body, so the title and Done button stay visible while the key fields scroll — no more overflow on short screens.
• Mobile-responsive. Tighter padding on small screens, full-width copy buttons that wrap instead of overflowing, and 100dvh sizing that accounts for mobile browser chrome.

Scoped to the credentials modal; other modals are unaffected.

Docker: docker pull viibeware/tspro-backup:1.0.2

Full diff: v1.0.1...v1.0.2

v1.0.1

Quality-of-life improvements to site credentials and connection details.

Added

• API endpoint in the one-time site-credentials modal, with its own copy button.
• Encryption key fingerprint in the same modal — copyable, so you can confirm it against TS Pro right after creating or rotating a keypair.

Changed

• Click-to-copy API endpoint and fingerprint on the site edit page, with a hover tooltip that flips to “Copied!”.
• More prominent connection-detail values (boxed, higher-contrast chips).
• Tidied the credentials modal so the API key label no longer wraps onto two lines.

Docker: docker pull viibeware/tspro-backup:1.0.1

Full diff: v1.0.0...v1.0.1

v1.0.0 — First public release

TS Pro Backup v1.0.0

Off-site, zero-knowledge backup storage for Trusted Servants Pro.

This is the first public release. Deploy TS Pro Backup somewhere separate
from your portal, point each TS Pro site at it, and your backups land here —
end-to-end encrypted, retained on a grandfather-father-son schedule, and
browsable from a web console that matches the TS Pro look.

Why it exists

A backup that lives next to the thing it's backing up isn't really a backup.
TS Pro Backup is the receiving half of an off-site pair: each portal pushes
its archives here over an authenticated HTTP API, and this server is the only
place those archives live off-site.

Highlights

• 🔑 Zero-knowledge by default. Every site gets its own X25519 keypair.
  TS Pro encrypts each archive to the site's public key before it leaves
  the portal; the private key is shown once at site creation and never
  stored here. The server holds only ciphertext and rejects any upload that
  isn't already encrypted (when require_e2ee is on). A full server
  compromise still can't read your backups.
• 🧱 Encryption at rest. Optional second layer over the storage volume —
  streaming AES-256-GCM, PBKDF2 (600k iterations). Defense-in-depth for the
  disk, independent of the end-to-end layer above.
• 🗓️ GFS retention. Keep N recent days / weeks / months / years, applied
  independently per scope so frontend snapshots never evict whole-site
  backups. An all-zero policy keeps everything.
• 🌐 Drop-in HTTP API mirroring TS Pro's put / list / delete / fetch
  backup-backend shape, with single-shot and chunked uploads for
  multi-GB bundles behind a proxy body cap.
• 🎛️ Web console — dashboard, per-site API keys, and a backup browser
  with download / delete, styled to match Trusted Servants Pro.
• 🔐 Cloudflare Turnstile on the console login (optional).

Install

docker pull viibeware/tspro-backup:1.0.0

Or with Docker Compose — see the README
for the full walkthrough.

⚠️ Keep your keys

Two secrets, lost, mean permanently unrecoverable backups — by design:

• the per-site private key (the only thing that decrypts your archives), and
• the at-rest passphrase / data/rest.key, if you rely on encryption at rest.

Store both in a password manager. This server keeps a copy of neither.

License

AGPL-3.0-or-later.