Docs: a security policy, and packaging metadata that matches the backends

[bmxcode]

GitHub's repository insights recommend adding a security policy. The generic template would have been worse than nothing here: it would have pointed at a reporting channel that is switched off, and said nothing about where this project's risk actually lives. Alongside it, the packaging metadata is brought back in step with what the tool reads.

The security policy

The threat model is stated plainly, because it is unusual and it is the whole point. samplerdisc has exactly one untrusted input: a disc image, usually downloaded from archive.org or a stranger's FTP, whose every offset, length, partition count and sample name was chosen by whoever built it. The parsers are the security surface of this project, and nothing else is.

What the tool does with that image is narrow, and the policy bounds it with four claims checked against the source rather than assumed:

• No network. Nothing in src/ imports socket, urllib, http or anything similar. The full set of non-project imports is argparse, array, collections, dataclasses, hashlib, itertools, json, os, re, struct, sys, typing, zlib.
• No subprocess, eval, pickle or shell. Nothing is deserialised and nothing is executed.
• No dependencies (ADR-0001), so there is no third-party supply chain to compromise.
• Input images are opened read-only — every container is open(path, "rb").

In scope, and to be reported privately: writing outside the output directory, code or command execution from image content, reading files other than the image given, and resource exhaustion out of proportion to the input. Each is tied to the code that defends it — the path-escape entry names safe_name() and its allowlist, and the exhaustion entry notes that compressed .mdx inflates in bounded blocks rather than in one call.

Out of scope, and routed to the public issue templates: a crash or traceback on a damaged image. That is a real bug, and the project rule is that damaged input degrades and never crashes — but it is not a security boundary. The tool runs with the reporter's own privileges, on a file they chose to hand it. Saying so keeps the private channel for the things that need it.

The ADR-0008 rule is repeated where a reporter will meet it: never attach a disc image or extracted audio. A crafted minimal reproducer is more useful anyway, and it is the one kind of image that may be attached.

What it deliberately does not claim

No email address. CODE_OF_CONDUCT.md already routes reports through GitHub rather than a mailbox, and inventing an address for the security policy alone would have contradicted it.

No service level agreement. The policy says to expect an acknowledgement in about a week and states why that is the realistic figure — one maintainer, no on-call. A 24-hour promise on a hobby project is a promise that gets broken the first time someone relies on it.

No support matrix beyond the current release. 0.3.x is supported, 0.2.x and earlier are not, and the upgrade path is upgrading. There is no backport branch, and pretending otherwise would be bookkeeping.

The packaging metadata

pyproject.toml was stale at v0.2 in the same way the repository description was. Its summary read "AKAI and friends", which hides three implemented backends, and its keywords named no E-mu, no Roland, no ISO 9660 and no AIFF — so the tool was undiscoverable by the formats it grew.

The summary now names AKAI, E-mu and Roland, and the keyword list is kept deliberately in step with the repository topics, so that the next time one is refreshed the other is the obvious companion edit.

Follow-up, not included here

Private vulnerability reporting is currently disabled on this repository, so the "Report a vulnerability" button the policy points at does not yet exist. Enabling it is a repository setting rather than a change to the tree, and it needs doing for this policy to function:

gh api -X PUT repos/bmxcode/samplerdisc/private-vulnerability-reporting

The repository description and topics carry the same v0.2 drift the packaging metadata did. They are settings rather than tree content, so they are handled separately alongside the setting above.

Verification

Documentation and packaging metadata only; no source changes. pyproject.toml is what builds the distribution, so it was put through the full ritual rather than eyeballed:

• uv run ruff check . — all checks passed
• uv run ruff format --check . — 90 files already formatted
• uv run pytest — 286 passed, 56 skipped (the skips are the real-disc tests, SAMPLERDISC_TEST_DISCS unset)
• uv tool install --editable . && samplerdisc --version — 0.3.0

Every relative link in SECURITY.md resolves against the tree, and each paragraph is a single line per the project's markdown rule.