docs: scaffold the Integration Kit — front page, outline, and the checks
Phase 5 slice 0 (MODULE_SYSTEM.md §2.11.1). The repo's governance, the front page, the book's outline, and the CI that keeps the whole thing from rotting. README.md What the reader is building, all three parts, and the draft banner: the kit is finished when someone outside this project builds a working module by following it alone, and that has not happened. Says the sidecar rule plainly (MODULE_API.md §2.7) rather than leaving it to chapter 3, because a reader who skims the front page and starts coding should still get that one right. book/README.md The outline of four chapters, landed before the prose so the shape can be argued with. Chapters are named but NOT linked — a link to a file that does not exist is what the link check is for, and an outline should not be the first thing to fail it. CONTRIBUTING.md The rule that governs every change here: the kit never re-specifies a contract. Also the prose conventions, and why the pinned ref points at core's `edge` rather than `main`. SECURITY.md Scoped for a repo that runs nothing: the two things that ARE reportable are a template that teaches an insecure pattern (it is meant to be copied) and a chapter that teaches something dangerous. scripts/checkLinks.js Relative links resolve; anchors match a real heading; no link pins a reader to a commit snapshot of a moving document. Nothing is fetched — a self-hosted Gitea would fail on a credential-less runner and teach us to ignore red. Fences and code spans are stripped by a line walk, not a regexp. Its first run found a real one: a PR template's relative links resolve from the REPO ROOT, because that is where their text ends up when Gitea inlines them into a pull request body. Encoded, with the reason. scripts/checkCoreApi.js The anti-rot check. Asserts template/module.json's `coreApi` EQUALS the pinned core's MODULE_API_VERSION — equality, not "satisfies", because a range check stays green across a contract bump and green would then mean "the template still loads" instead of "someone has re-read the book". Both failure branches and the pass were exercised against a real core checkout. ci/core-ref.json The pin, same convention as Module-uo's. Points at `edge`: core's `main` has no server/src/modules/ until the cutover, and that pin is one of the things the cutover has to revisit. .gitea/workflows/pr-checks.yml Two jobs. `links` always runs; `template` is conditional on template/module.json existing, so the repo is gated now and the job arms itself when slice 1 lands, with no edit to the workflow. Same guard Module-uo used through its planning phase. Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
76
SECURITY.md
Normal file
76
SECURITY.md
Normal file
@@ -0,0 +1,76 @@
|
||||
# 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).
|
||||
|
||||
## What this repo is, for scoping purposes
|
||||
|
||||
This repo is **documentation plus a template module**. It runs nothing, listens on
|
||||
nothing, and stores no data. Two kinds of report are still in scope here, and both
|
||||
are worth sending:
|
||||
|
||||
- **The template teaches an insecure pattern.** It is meant to be copied, so a
|
||||
weakness in it propagates into every module written from it — an unparameterised
|
||||
query, a route missing an authorisation check, a secret handled in the clear, a
|
||||
permissive CORS or CSP suggestion. Treat the template as production code that has
|
||||
not been deployed yet.
|
||||
- **A chapter teaches something dangerous.** Advice that would lead a reader to
|
||||
expose their game server to the internet, hold a secret unencrypted, bypass core's
|
||||
authorisation middleware, or weaken session handling is a security issue in this
|
||||
repo even though no code here does it.
|
||||
|
||||
A defect in core, a module or the sidecar itself belongs to that repo:
|
||||
[`website`](https://gitea.whitlocktech.com/RunicGateway/website),
|
||||
[`Module-uo`](https://gitea.whitlocktech.com/RunicGateway/Module-uo),
|
||||
[`link`](https://gitea.whitlocktech.com/RunicGateway/link).
|
||||
|
||||
## Three things that are policy, not oversight
|
||||
|
||||
A module author reading this kit should know these up front, because they shape what
|
||||
counts as a vulnerability anywhere in this project:
|
||||
|
||||
- **The module boundary is not a security boundary.** A module runs in the same Node
|
||||
process as core, with the same privileges, against the same database. It is a
|
||||
code-organisation and distribution boundary. Installing a module is the same trust
|
||||
decision as installing the site — which is why installation is admin-only. "A
|
||||
module could reach core's internals" is not a vulnerability report; "an
|
||||
unprivileged user can install or enable a module" very much is.
|
||||
- **Access control lives in core.** Route protection is core's middleware, and what
|
||||
a visitor may see of live game state is the website's admin-toggleable visibility
|
||||
framework. A module route that reaches game data without going through those is a
|
||||
security bug. A sidecar that makes its own access-control decisions is a design
|
||||
error — it is a forwarder.
|
||||
- **The website process never connects to a game server.** The game is not
|
||||
network-reachable; it dials out to a sidecar, and only the website's backend talks
|
||||
to that sidecar. This is a rule in the module contract
|
||||
([`MODULE_API.md`](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/website/MODULE_API.md)
|
||||
§2.7), and a chapter or template that leads someone to break it is the kind of
|
||||
report this repo most wants.
|
||||
|
||||
## Supported versions
|
||||
|
||||
This project is developed continuously and does not maintain long-term release
|
||||
branches. Fixes land on `main`; please read a recent copy.
|
||||
Reference in New Issue
Block a user