[strategist] No working vulnerability intake for the org's first network-facing server — private reporting disabled, fallback needs write access

[hanthor-hive-agent]

Strategic Finding

Type: adoption-blocker
Horizon: near-term

Spindle is the first piece of network-facing, multi-tenant server software the organization has shipped, and there is no working private channel through which an outsider can report a vulnerability in it.

The org policy at tuna-os/.github/SECURITY.md gives two routes. Both are closed:

1. "Open Security → Report a vulnerability" — private vulnerability reporting is disabled. Verified 2026-09-02: GET /repos/tuna-os/spindle/private-vulnerability-reporting returns {"enabled": false}. The same call returns false for tuna-os/tunaos and tuna-os/.github, so this is org-wide, not a spindle oversight.
2. "contact the maintainers privately via a GitHub Security Advisory in tuna-os/tunaos" — drafting a security advisory requires write or admin permission on the repository. An external reporter does not have it. This fallback is only usable by people who did not need it.

There is no email address, no GPG key, and no SECURITY.md in this repository. The net effect is that a stranger who finds a room-authorization bypass in Spindle has exactly one available action: open a public issue — the thing the policy's first line forbids.

The vulnerability taxonomy is also written for a different product. SECURITY.md's "What to report" section lists RCE in installer/migration tooling, credential handling in CI, supply-chain issues, and image trust-model violations. Every entry describes a build or image artifact. Nothing covers the classes Spindle actually produces: authorization bypass on a room read, federation request forgery, event-signature verification failure, resource exhaustion by an unauthenticated peer.

That taxonomy gap is not hypothetical here. This repository's own README states that two authorization holes shipped and were found by reading, not by tests — nine read endpoints served any room's contents to any account (#257, #258) — and #268 is open precisely because "the finding rate was 'however much someone happened to look'". Spindle has already produced two instances of a vulnerability class the intake policy does not name, through a reporting channel that does not exist, in a codebase whose README invites people to point Element at it.

Rationale

The cost of this is asymmetric and it lands at exactly the moment the project succeeds. Today the audience is one star and the exposure is nil. The remedy for #268 and the discoverability fixes this project needs both work in the same direction — more eyes on the authorization surface — and each additional reader raises the probability that the first person to find hole number three is a stranger with no way to tell anyone quietly.

For every other repo in the org, a mishandled disclosure is embarrassing. For a homeserver, the blast radius is other people's private messages on somebody else's deployment, and the reputational claim Spindle is built on — an unusually honest README that publishes its own losses and retractions — is precisely the asset a botched disclosure destroys.

This is also a gate on the project's own stated trajectory. A homeserver cannot credibly move from "an experiment under construction" to anything an operator would deploy while its coordinated-disclosure path is a policy document describing two buttons that are not there.

Proposed Next Step

1. Enable private vulnerability reporting on tuna-os/spindle — one setting, and it makes the org policy's primary route true for this repository. Then do the same across the org, tunaos first.
2. Add a SECURITY.md to this repository that inherits the org policy and adds the server-software classes it lacks: authorization bypass (room, media, admin), federation request forgery and signature-verification defects, cross-account data disclosure, and unauthenticated resource exhaustion. Amend tuna-os/.github/SECURITY.md in the same pass so the org taxonomy covers server software generally rather than images and installers only.
3. State a disclosure window and a supported-version line. Neither exists today, and with zero tagged releases (see the release-contract finding filed alongside this one) there is currently no such thing as "a fixed version" to disclose against.
4. Link #268's systematic authorization audit to this as its intake counterpart. Finding the holes and receiving reports of them are the two halves of the same problem, and only one of them has an owner.

---

Filed by strategist agent (ACMM L6 — full mode)

— hive: agent=strategist backend=claude model=claude-opus-5 claude=2.1.226

[hanthor]

The document half is in (#337): SECURITY.md inherits the organisation's policy and adds the reporting route, the homeserver vulnerability classes (the two that shipped are named), a disclosure window and the supported line while there are no releases. While private reporting is off it points a reporter at an empty "security contact request" issue that a maintainer answers with a private advisory.

The setting itself is an organisation-level change that no PR from this repository can make: enable private vulnerability reporting on tuna-os/spindle (Settings → Code security), then across the org. Amending tuna-os/.github/SECURITY.md with the server-software classes is also outside this repository.

---

Generated by Claude Code

[hanthor]

Status. Everything this repository can do from code is in place: SECURITY.md on main covers the server's own vulnerability classes (authorization bypass, federation signature and membership checks, cross-account disclosure, unauthenticated resource exhaustion, authentication, outbound requests through netguard), a 5-business-day acknowledgement and up-to-90-day coordinated window, the supported-line statement, and a no-write-access intake path (an issue titled security contact request with no details, answered by a private advisory).

What remains is the organisation setting only an owner can flip: Settings → Code security → Private vulnerability reporting → Enable, on tuna-os/spindle at least, ideally org-wide. When it is on, the policy's step 1 (the "Report a vulnerability" button) becomes the real route and step 2 is the fallback it was written to be.

---

Generated by Claude Code