RimMap edits files that represent hundreds of hours of someone's play. In this project, data loss is treated as a security issue, not a bug — the two are reported through the same channel and get the same priority.

Fixes land on the latest release. There are no long-term support branches.

Report privately if you find any of:

• A path by which the input save is modified or destroyed. The importer must never write to the file given to --save.
• A path by which a file is written that the user did not name — anything outside --out (or its <save>-custom.rws default), its .part temp file and its .bak backups.
• A backup being clobbered or skipped when it should not be, or a write that is not atomic and can leave a truncated .rws under the real filename.
• Output that corrupts a save, including malformed XML, colliding thing IDs, or anything that makes RimWorld fail to load a file RimMap wrote.
• Arbitrary code execution, command injection or path traversal reachable from an import code, a blueprint JSON, a filename or a save file. An import code is something people paste from strangers, so it is untrusted input by design.
• Anything that sends data off the machine. RimMap does not do this, and any path that does is a serious bug.
• Anything reaching the local server that should not. A request accepted without a valid X-RimMap-Token; a request accepted from a non-loopback peer; a DNS-rebinding or cross-origin request that gets past the Host, Origin and Sec-Fetch-Site checks; a CORS preflight answered with any Access-Control-* header; a path traversal through save_id or out_name; a write outside the chosen save folder; or any way to make the server read or serve a file from disk that is not the designer page.

• The importer producing an ugly or unplayable map. That is a normal bug — use the issue templates.
• Using RimMap on a mid-game colony and disliking the result. The output goes to a new file and the original is untouched; see docs/SAFETY.md.
• --force letting you past the validation gates. That is what it is for, and it is documented.
• Reports produced by an automated scanner with no working example.

Use GitHub's private vulnerability reporting: open the repository's Security tab and choose Report a vulnerability. That creates a private advisory visible only to the maintainer.

If that is unavailable to you, open a normal issue containing only "security report, please contact me" and nothing else, and you will be contacted to continue privately. Do not put the details in a public issue.

Please include:

1. What happens, and what you expected instead.
2. The exact command or steps, with the import code if one is involved.
3. RimMap version (rimmap/__init__.py), Python version, operating system.
4. Whether any file was lost, and which one.

Do not attach a real .rws save. They are large and personal, and the output of python3 -m rimmap inspect --save "<path>" almost always contains what is needed. If a specific file really is required to reproduce it, say so and it will be arranged privately.

This is a hobby project maintained by one person, so no response-time commitments are made. In practice: an acknowledgement as soon as it is seen, a fix for anything that can destroy a save prioritised above everything else, and credit in CHANGELOG.md unless you would rather not be named.

Please give a reasonable window before disclosing publicly — for a save-destroying bug, long enough for a release to exist that people can update to.

Facts about this version, so you know what surface you are looking at:

• No dependencies. RimMap imports only the Python standard library. There is no supply chain to compromise and nothing to install.

• Nothing is sent off the machine. There is no outbound network code at all: no update check, no telemetry, no analytics, no crash reporting. The designer page loads no external scripts, fonts or images; the only external URLs in it are links you can choose to click.

• The one server is local, and treated as a security surface. rimmap gui runs an HTTP server for the designer page, defended in four independent layers, all of which must fail before anything an attacker controls reaches a save file:

  1. Loopback only — bound explicitly to 127.0.0.1, never 0.0.0.0, and every request's peer address is re-checked against the loopback set.
  2. A per-run token — secrets.token_urlsafe(32), injected into the page, required in a custom X-RimMap-Token header and compared with hmac.compare_digest. It is never in the URL bar and never a cookie, so it cannot leak through Referer, history or an ambient-credential request; and because it is a custom header, any cross-origin attempt is forced into a preflight, which is answered 403 with no Access-Control-* header at all.
  3. Host pinning — the Host header must name our own loopback origin. This is the anti-DNS-rebinding check.
  4. Origin / Sec-Fetch-Site — when present, they must say same-origin.

  It also exits by itself once the page stops checking in, so a closed tab does not leave a server running.

• No static file handler. The server subclasses BaseHTTPRequestHandler, never SimpleHTTPRequestHandler, so there is no directory to walk and no listing to leak; / returns an in-memory string.

• The browser never names a filesystem path. It sends an opaque save_id minted by the server's own scan, which makes traversal unrepresentable rather than merely blocked. The single endpoint that accepts a path only adds a folder to the scan list, and validates it first.

• Untrusted input is parsed, not evaluated. Import codes are split and converted with int(); blueprints are json.loadsed; saves are parsed with xml.etree.ElementTree. Nothing is evaled, and nothing is passed to a shell — the one place a system tool is invoked (opening your file manager on a folder the server itself chose) uses an argv list, never shell=True.

• Writes are confined to the output path, its .part temp file and its .bak backups, all in the folder the user chose.

RimMap is an unofficial fan-made tool, not affiliated with or endorsed by Ludeon Studios. RimWorld is a trademark of Ludeon Studios.