Files

wtclaude d2b311197b chore(installer): bootstrap repo with governance docs and templates

The installer repo was created empty. Seed it with the same governance set
every other Runic Gateway repo carries, so it starts on the same footing
before any Rust code lands (see docs/installer/PLAN.md for the design of
record — this repo is still in the planning phase).

Copied verbatim, byte-identical to the other repos:

  LICENSE.md (GPL-3.0-or-later), CODE_OF_CONDUCT.md, CONTRIBUTORS.md,
  .gitea/PULL_REQUEST_TEMPLATE.md, .gitea/ISSUE_TEMPLATE/{bug_report,
  feature_request}.md

Repo-specific:

  README.md          what the installer is, what it deliberately is not
                     (no curl|bash, never writes a ServUO launcher), the
                     planned commands, and the constraints a reader needs
                     up front: unsigned releases, bundle-manifest
                     composition, opt-in patch tier, and the fact that a
                     successful copy is not a working bridge.
  CONTRIBUTING.md    adapted from link/ (same Rust toolchain and checks),
                     plus a planning-status note pointing changes of scope
                     at the plan in docs/, and the two shard-testing traps.
  SECURITY.md        adds the installer to the component scope table and a
                     short subsection on its distinct trust model: unsigned
                     releases anchored on SHA256SUMS, mandatory
                     verification of downloaded artifacts, and the
                     never-contacts-the-website token handoff. This is the
                     only file that now differs from the other repos' copies.
  .gitignore         Rust build output plus local deployment state
                     (install.json, sidecar.toml, *.db) that must never be
                     committed from a test run.
  .gitea/ISSUE_TEMPLATE/config.yaml   same as elsewhere, repo-local URL.

No CI workflows yet — there is no crate for pr-checks to build, and the
release/bundle workflows are Phase 0 work that depends on servuo-plugins
gaining a release workflow first.

Co-Authored-By: Claude <noreply@anthropic.com>

2026-08-04 09:05:56 -05:00

3.1 KiB

Raw Blame History

Security Policy

Thank you for helping keep Runic Gateway and its users safe.

Reporting a vulnerability

Please do not report security vulnerabilities through public issues, pull requests, or the wiki. A public report tips off attackers before a fix is available.

Instead, report privately by email to:

whitlocktech@gmail.com

Please include as much of the following as you can:

The repository and component affected.
The type of issue (e.g. authentication bypass, injection, secret exposure, remote code execution, denial of service).
Step-by-step instructions to reproduce, and a proof-of-concept if you have one.
The impact — what an attacker could do with it.
Any suggested remediation.

You will receive an acknowledgement of your report, typically within a few days. We will keep you informed as we investigate and work toward a fix, and we are happy to credit you in the release notes once the issue is resolved (let us know if you would prefer to remain anonymous).

Scope

Runic Gateway is a self-hosted platform made up of several components:

Component	Repo	Network exposure
Website (site + admin + API)	`RunicGateway/website`	Internet-facing (behind a reverse proxy)
uo-link sidecar	`RunicGateway/link`	The only network-facing part of the game bridge
ServUO plugin	`RunicGateway/servuo-plugins`	Loopback only — dials the sidecar on `127.0.0.1`
Installer	`RunicGateway/installer`	Not a service — an operator-run deployment tool (see below)
Documentation	`RunicGateway/docs`	Content only

Because instances are self-hosted, the security of any given deployment also depends on how it is configured and operated — strong secrets (JWT_SECRET, SECRET_ENC_KEY, database and admin passwords), a correctly configured reverse proxy and TRUST_PROXY, and keeping the shard itself unreachable from the internet (only the sidecar should be exposed). See each repo's README for the security model.

Installer-specific notes

The installer runs with elevated privileges on the shard host, downloads other components, and handles the sidecar's auth token. Three things follow from that, and they are policy rather than oversight:

Releases are unsigned. SHA256SUMS, published with every release, is the trust anchor. Verify the checksum of any installer binary before running it. Windows SmartScreen and macOS Gatekeeper warnings are expected.
The installer verifies what it downloads. Component artifacts (the sidecar binary, the overlay tarball) are checked against the publishing repo's SHA256SUMS and refused on mismatch. A report of a bypass in that check is a security issue, not a bug report.
The installer never contacts the website. It prints the sidecar's base URL, WebSocket URL, protocol version, and auth token for the operator to paste into Admin → Shard. Anything that would transmit that token automatically is out of scope by design.

Supported versions

This project is developed continuously and does not maintain long-term release branches. Security fixes land on main; please run a recent build.