mirror of https://github.com/J3vb/OwnCord.git synced 2026-09-03 03:50:00 +03:00

Files

T

J3vbandClaude c0c8736674 B1-7: community intake and automation authorization (RL-21 / L-15, RL-22 / L-16, RL-16 / R-09) (#1419 )

* ci(claude): constrain automation triggers and bound run cost (L-16)

The Claude Code workflow consumes a metered credential, and the repository
stated nothing about who may spend it or for how long. Whatever downstream
behaviour happens to hold, an invariant this repository depends on should be
asserted and tested here, not inherited from a pinned dependency that a routine
version bump can re-derive.

Three controls, in the one workflow that spends:

- **Authorization.** The job condition now requires the actor to be on an
  explicit maintainer allowlist as well as the trigger text to mention the bot.
  An allowlist rather than an association check: this repository has exactly one
  collaborator, the term is unambiguous to read and to review, and it matches
  the actor-term pattern `ci.yml` already uses to exclude Dependabot. Adding a
  login is a one-line edit, which is the honest cost.
- **Duration.** `timeout-minutes: 30`, in the band every other long-running job
  here uses. Without it the job inherits GitHub's 360-minute default — the wrong
  ceiling for metered work, and the only job in the repository that lacked one.
- **Fan-out.** A `concurrency` group keyed on the issue or pull request number
  with `cancel-in-progress: true`, so repeated triggers on one thread collapse
  into a single run instead of running in parallel. Exactly one of
  `github.event.issue.number` and `github.event.pull_request.number` is present
  per triggering event, so the key is stable across all four.

The `permissions:` block and the checkout are deliberately untouched. The
permissions are already minimal and the checkout takes no `ref:`, so it reads
the base branch rather than proposed code — both correct, and rewriting either
would be churn.

`scripts/check-workflow-guards.mjs` keeps all three from silently regressing.
Modelled on `scripts/check-doc-counts.mjs`: same `--selftest`-then-assert shape,
same dependency-free approach. It is text-level rather than YAML-parsed on
purpose — the root has no YAML parser, and adding a dependency to assert that a
file contains a `timeout-minutes` key would be a poor trade. That limit is
stated in the file: these are presence-and-shape checks, not semantics.

It runs from `CHECK_HYGIENE` in `scripts/run.mjs`, so it is reachable as
`npm run check:hygiene` locally and executes inside `Repository Hygiene`, which
is already a pinned required check on `dev`. No new CI job and no new pin — the
guard is blocking from the moment it lands.

`actionlint` cannot do this job. It validates expression syntax, action inputs
and runner labels; a job condition is valid input to it whatever the condition
admits, and it has no notion of cost at all. The two tools are complementary
and both now run.

Also corrects the record: `docs/plans/b1-repository-foundation-2026-08-25.md`
claimed impact was bounded by read-only content permissions. The workflow's own
token block is least-privilege, but that is not the only identity a run can
hold, so the claim was narrower than the truth and is now stated accurately.

And `docs/security.md` gains the private-coordination section that two planning
documents already cite it for. The citation pointed at a policy that was not
written down; it now says what stays private, that the rule covers the
repository's own automation and settings rather than only product code, and
that a commit message on a public repository is a disclosure channel.

Verified: both directions, per guard. `node scripts/check-workflow-guards.mjs`
exits 0 on the current tree and reports four guards present. Deleting the
`timeout-minutes` line makes it exit 1 naming that guard and the invariant to
restore; replacing the actor term with `true` makes it exit 1 naming that one;
restoring each returns exit 0. `--selftest` passes eight assertions covering
every guard's absence, a commented-out guard (which must not count), and the two
shapes that must not trip it — any positive timeout value, and any concurrency
key. `npm run check:hygiene` passes with prettier, shellcheck, actionlint and
both new steps running for real; actionlint accepts the edited workflow.

Not included: the workflow's `permissions:` block and checkout step, per above.
No change to the action version or its inputs. `ci.yml`, `release.yml` and
`load-baseline.yml` are outside this item — none is reachable the same way, and
each already carries per-job least-privilege permissions, and where relevant a
timeout and a concurrency group. `METERED` in the new script lists one workflow
because one workflow spends; a second entry is a one-line change when that
changes.

Refs RL-22, L-16

* feat(intake): structured bug form, and route ideas to Discussions (RL-21)

Both issue templates were Markdown with front matter, so nothing they collected
was structured, required, or validated. A reporter could submit the form
untouched. The Environment block was three bullets with `Windows 11` prefilled
as the OS — the single most common answer, pre-filled, on a project that ships
Windows and Linux builds and an ARM64 client.

And `feature_request.md` existed at all, which is the direct violation: BPR-100
says Issues is the bug tracker and Discussions hosts support, ideas and
community feedback. A feature-request template routes ideas into Issues by
construction.

Done:
- `bug_report.md` → `bug_report.yml`, a real issue form. Six fields are
  `validations: required` — what happened, steps to reproduce, component, OS,
  architecture, deployment mode — because those six are what turns a report into
  something reproducible. The rest are optional on purpose; a form that demands
  everything gets abandoned.
- `feature_request.md` deleted. Nothing in the tree referenced either template
  by filename, so this breaks no link, script, or workflow.
- `config.yml` gains three routed destinations and keeps `blank_issues_enabled:
  false` — which is what makes the routing hold, since a blank issue bypasses
  every form and every warning on one.

The new environment fields are drawn from what this project actually ships, not
from a generic template:
- **Architecture** x64 / ARM64, with the note that ARM64 is the Linux desktop
  client today and there is no ARM64 server release.
- **Deployment mode** covering the six paths `docs/deployment.md` documents —
  prebuilt binary on either OS, from source, Docker/Compose, systemd, Windows
  service.
- **TLS mode** matching `tls.mode`'s four values exactly, `off` quoted so YAML
  does not read it as boolean false.
- **Network topology** — direct, port forward, reverse proxy, Tailscale — because
  voice bugs in particular bifurcate hard on this, and the reverse-proxy path
  cannot carry the WebRTC UDP range at all.
- **Separate client and server versions.** They are obtained differently and can
  legitimately differ. The server field says where to look — admin panel or the
  startup banner — and explicitly tolerates "unknown", because the version is
  deliberately absent from the unauthenticated `/health` endpoint as
  anti-fingerprinting hardening, so a non-admin reporter genuinely cannot get it.
- **Client webview**, WebView2 or WebKitGTK. No "PWA" option: no PWA exists, B1
  excludes browser and PWA work, and BPR-092 forbids presenting unavailable
  behaviour as functional. The field is diagnostic today regardless — the desktop
  client renders through the OS webview, and that already drives real bug classes.

Every public template now carries the disclosure warning BPR-101 asks for, and
the security contact link is first in the chooser, above the Discussions links.

Four files, 189 insertions, 58 deletions.

Verified: both files parse as YAML, and the form was checked against the issue
form schema rather than only for parseability — 13 body elements, 12 unique ids
with no collisions, every non-markdown element carrying an id and a label, every
dropdown carrying options, and the markdown block carrying neither an id nor
validations (both of which GitHub rejects). `config.yml` has
`blank_issues_enabled: false` and four contact links each with exactly
name/url/about. `npm run check:hygiene` passes.

The gap that verification leaves, stated plainly: nothing in this repository
validates issue-form schema. Prettier confirms the YAML parses and actionlint
does not read `.github/ISSUE_TEMPLATE/` at all, so a file that is valid YAML but
an invalid form disappears from the "New issue" chooser silently. The checks
above are a local stand-in, not the real gate. The live chooser needs a look
after merge — which BPR-100's closure evidence ("dry-run submissions reach the
intended destination") requires in any case.

Not included: the Discussions `?category=` slugs are written as `q-a` and
`ideas`, GitHub's defaults. If this repository's categories were renamed, a
wrong slug drops the user on the category picker rather than erroring — confirm
against the live Discussions tab before relying on them. No PR-template or
documentation changes here; those are the next commit. L-15 is not closed by
this commit alone: BPR-100 names six surfaces and three of them are docs.

Refs RL-21, L-15

* docs(intake): route contributors, and state the security path (RL-21)

The previous commit fixed the forms. This is the half BPR-100 and BPR-102
actually ask for and the B1 plan's bullet does not mention: their closure
evidence names repository navigation, support links and contribution docs
alongside the issue forms, so a `.github/`-only change cannot satisfy either.

Three gaps, each verified rather than assumed:

**Discussions was invisible.** The only link to it anywhere in the tree was
inside `.github/ISSUE_TEMPLATE/config.yml` — the new-issue chooser. So "route
ideas and feedback to Discussions" worked for exactly one audience: people who
had already decided to file an issue. `README.md` and `docs/README.md` now each
carry the routing, so it is reachable from the two pages a newcomer actually
lands on.

**`docs/contributing.md` never mentioned security reporting.** Five files
carry the "never a public issue" rule — the root `README.md`, `CONTRIBUTING.md`,
`SECURITY.md`, `docs/security.md`, `CLAUDE.md` — and every one of them delegates
the full process to `docs/contributing.md`, which is also the document BPR-102's
evidence row sends a fresh contributor to. It said nothing about it. It now has
a routing table and a security section that says the thing that actually matters
on a public repository: the PR description, the commits and the branch name are
disclosure channels, so a fix for a vulnerability describes the control it adds
and nothing else.

**The README contradicted the issue chooser.** The banner said "there's no
support" while the chooser offered a link named "Community Support". Both were
defensible in isolation and together they told a user two different things
before they had read anything else. The banner now says the honest version — no
support *commitment* — and a "Getting Help and Reporting Problems" table names
the right destination for each kind of message without promising a response.

Also in the PR template, which the audit's remedy names as "PR guidance":
- The Test Plan asked for `npm test` / `go test ./...` / `npx tsc --noEmit`.
  Those predate B1-4's root facade; `npm run check` is the entry point CI gates
  on and the one `CONTRIBUTING.md` and `README.md` now tell people to run.
- A generated-files checkbox naming all five, since CI fails on drift and a
  hand-edited generated file is the failure that wastes a cycle.
- A `Not included:` prompt, because `docs/contributing.md` makes a written
  deferral a required commit element and the template asked for it nowhere.
- The disclosure warning BPR-101 wants on public templates.

Two stale claims fixed while in these files: `docs/contributing.md` said "ten
status checks are required" three lines from a section that says twelve, and
`docs/plans/README.md` still read "B1-0 done, B1-1 next" six phases later — in
the index that declares itself the authority over plan headers.

Five files, 70 insertions, 12 deletions.

Verified: `git grep "ten status checks"` returns nothing.
`node scripts/check-doc-counts.mjs` still agrees on 21 claims across 8 watched
documents — `docs/plans/README.md` and `README.md` are both watched, so a
count claim broken by these edits would have failed here.
`npm run check:hygiene` passes with prettier, shellcheck, actionlint and the
workflow-guard check all running.

One nearby claim checked and deliberately left: `docs/contributing.md` also says
"four of the ten" a hundred lines later. That is four of ten *CI steps keying on
a cache-dependency-path*, not required checks — correct in context, and changing
it would have been a wrong fix to a right-looking grep hit.

Not included: L-15 is **not** closed. BPR-100's closure evidence requires
dry-run submissions that reach the intended destination, and BPR-102's requires
a fresh Windows and Linux contributor to follow these docs and land a passing
sample change. Neither is a file edit. BPR-101 additionally wants a tabletop
report proving private receipt, triage, advisory and coordinated disclosure —
no such artifact exists in the tree, and this commit does not create one.
`CODE_OF_CONDUCT.md` and `GOVERNANCE.md` do not exist in this repository; adding
them is community-health scope, not RL-21's, and neither is named by the audit
row or the register row.

Refs RL-21, L-15

* ci(release): require exact-SHA gate evidence before publishing (RL-16)

A tag push starts `release.yml` and nothing else — `ci.yml` has no `tags:`
trigger. And `release.yml` re-runs none of the required checks: it verifies the
version, builds, boot-smokes and signs, which is a different question from
"did the gate pass on this commit". So a tag could publish from a commit whose
CI was red, and nothing would notice.

It already has. `v1.2.0-alpha.3` published from `fb04a579`, whose CI run
concluded **failure** — `Server Build & Test (windows-latest)`, the race and
coverage step. The Release run on the same commit went green and shipped. That
is R-09 demonstrated rather than hypothesised, and it is the fixture this commit
is verified against.

The obvious fix — re-run the test suite inside `release.yml` — is the wrong one.
It would double the tag-time cost, still not cover the checks that run in other
workflows (CodeQL's three `Analyze` jobs exist in no workflow file at all), and
answer a weaker question: "does it pass now" rather than "did the gate pass on
this commit". The evidence already exists; nothing was reading it.

Done:
- `scripts/verify-gate-evidence.mjs` resolves the tagged SHA's check runs and
  asserts every required context is present and `success`. `skipped` and
  `neutral` are not success — a required check that skipped on the tagged commit
  proves nothing about it — and a still-`in_progress` check is called out as
  unfinished rather than treated as absent. Where a context reported more than
  once, the latest attempt decides, in both directions.
- The required set is **parsed out of `b0-dev-branch-protection.sh`**, not
  restated. Pinning a thirteenth check cannot leave this gate behind, and a
  change to that file's shape fails the self-test rather than silently
  weakening the gate.
- A `gate-evidence` job in `release.yml` that `verify-versions` needs. Every
  build job already needs `verify-versions` and both publishers need those, so
  one edge gates the whole graph — including the GHCR push, which today can
  mutate `:latest` before `publish` has run at all.
- `permissions: checks: read` and nothing else.

It is a script rather than a `run:` block because of the rule in the `ci-check`
skill: a step that exists only in `release.yml` first executes at tag time, so
its own bugs surface on the release. `Server/scripts/docker-smoke.sh` is the
worked example — one script, two call sites. Here the second call site is
`--selftest`, run by `ci.yml`'s docs-consistency job on every pull request.

`docs/plans/b1-release-tag-protection.sh` covers the half a workflow file
cannot express: a ruleset on `refs/tags/v*` blocking update and deletion, and a
`release` environment with a required reviewer. **NOT APPLIED** — both are
repository-settings writes this session cannot make. Run
`bash docs/plans/b1-release-tag-protection.sh` when you want them.

Deliberately **no `environment: release` key** in `release.yml` yet. The key is
PR-landable, but naming an environment that does not exist stalls the next
release; the script says to add it after creating the environment, and says why.

Verified: both directions, on real data rather than only fixtures. Feeding the
actual check runs from `fb04a579` — the commit alpha.3 shipped from — through
`evaluate` returns **NOT RELEASABLE**, naming `Server Build & Test
(windows-latest): failure` first. Feeding PR #1418's real check runs on
`8875238` returns **RELEASABLE**, and correctly ignores the red
`github-advanced-security` result because it is not a pinned context — the gate
tracks the required set, not "everything is green". `--selftest` passes 12
assertions covering a missing check, a failure, an unfinished run, `skipped`,
`neutral`, both re-run orderings, an unrequired extra, and a commit with no
checks at all. `bash -n` and `shellcheck` are clean on the new script and both
its heredocs parse as JSON. `npm run check:hygiene` passes with actionlint over
both edited workflows.

The module gained a direct-invocation guard so it can be imported and tested
without reaching the network — compared against `argv[1]` rather than
`import.meta.main`, which needs Node 24.2 against an engines floor of `>=24`
and would silently no-op on 24.0.

Not included: the network path itself is exercised only at tag time. The
self-test covers the decision logic and the required-set parsing, which is where
the bugs live; a live API call needs a token this environment does not have.
R-09's "protected release approval" limb stays open until the settings script is
run — the register phases R-09 **B1/B10**, so that half is B10's. `release.yml`'s
version stamping, both signing keys, the fail-closed minisign verify,
`checksums.sha256`'s bare filenames, both cold-boot smokes and the `git archive`
source snapshot are untouched; the remedy says to retain them and this commit
only adds an edge in front of them.

Refs RL-16, R-09

* docs(plans): record B1 progress through B1-7

B1-6 (#1418) merged and B1-7 is this branch, so the header and the plan index
both move on. B1-8 — the platform contract map — is next, and it is documentation
only: it records the browser-neutral contract folders and their owners, and moves
no native behaviour. Adapter extraction stays B7.

Verified: `node scripts/check-doc-counts.mjs` still agrees on 21 claims across 8
watched documents, both edited files among them; prettier clean.

Refs R-08

---------

Co-authored-by: Claude <noreply@anthropic.com>

2026-08-27 17:25:22 +00:00

8.7 KiB

Raw Blame History

Security Policy

Security guidelines and vulnerability reporting for OwnCord.

Reporting Vulnerabilities

Report privately via GitHub Security Advisories: github.com/J3vb/OwnCord/security/advisories/new.

Do NOT open public issues for security bugs.

The repository-root SECURITY.md is the canonical reporting policy — what to include and the response timeline (initial response within 7 days) live there, so the two files cannot disagree.

What stays private, and for how long

This applies to weaknesses in the repository's own automation and settings — workflow authorization, credential scope, release gating — as much as to bugs in the server or client. Planning documents cite this section as the rule; it is written here so the citation points at something.

Public artifacts — commits, issues, pull request descriptions, changelogs — carry an opaque identifier, the affected property, safe acceptance criteria, and a status. Nothing more.
Reproduction steps, source-to-sink traces, exploit conditions, and the state a fix replaced stay in the private advisory. A commit that fixes a weakness describes the control it adds, not the gap it closes.
Every private finding has exactly one public owner, so nothing is tracked only in private and nothing is silently dropped.
Release notes may describe repaired impact after coordinated remediation, without the detail needed to reproduce it.

This repository is public. A commit message is a disclosure channel.

Two-Factor Authentication

OwnCord supports TOTP-based 2FA:

Users enroll via Settings > Account (QR code + backup codes)
Admins can enforce server-wide 2FA via the require_2fa setting in the admin panel
require_2fa requires all users to have 2FA enabled and registration to be closed
Login flow returns requires_2fa: true with a partial_token (10-min TTL, 5-attempt limit)
Auth challenges are rate-limited to 10 req/min per IP
TOTP code verification uses constant-time comparison (subtle.ConstantTimeCompare) to prevent timing side-channel attacks

Account Deletion

Users can delete their own account via DELETE /api/v1/auth/account with password confirmation. The last admin account cannot be deleted. After 3 failed password attempts, the endpoint locks out for 15 minutes.

Audit Logging

Security-relevant actions are recorded in the audit_log table with actor, action, target, and detail:

Auth: user_register, user_login, user_logout, login_blocked_banned, account_deleted, password_change, session_revoke
2FA: totp_enabled, totp_verified, totp_disabled
Admin: role_change, role_create, role_update, role_delete, role_reorder, user_ban, user_unban, force_logout, setting_change, server_setup, api_token_create, api_token_revoke, config_write
Content: channel_create, channel_update, channel_delete, channel_perms_update, channel_perms_clear, channel_user_perms_update, channel_user_perms_clear, message_delete, message_purge, emoji_create, emoji_delete
Profile: profile_update, identity_key_update
Ops: backup_create, backup_delete, backup_restore, ws_connect

Note: backup_restore is written synchronously to the live database before the pre-restore safety copy is taken, so the row survives inside the pre_restore_*.db backup. The restored database itself will not contain it — the restore replaces the database file wholesale.

Client Security Hardening

The Tauri desktop client implements the following security measures:

Credential Storage

Credentials are stored in the OS keyring (Windows Credential Manager / macOS Keychain / Secret Service) via the keyring crate, with every write read back and verified; if no keyring is available they fall back to an encrypted file (Windows DPAPI with CRYPTPROTECT_UI_FORBIDDEN, ChaCha20-Poly1305 elsewhere) — see credential-storage.md
Plaintext passwords are never returned to the frontend over IPC — only tokens are accessible from JavaScript
Auto-login uses stored tokens for reconnection, not passwords

Tauri Capabilities (Least Privilege)

Filesystem write access is scoped to $APPDATA/** and $APPLOG/** only
DevTools command is gated behind the devtools feature flag (excluded from release builds)
HTTP fetch is restricted to https:// origins plus http://127.0.0.1:* (the Rust TOFU proxy's loopback tunnel), and denies https://localhost[:*] and https://127.0.0.1[:*] — no legitimate flow reaches loopback over https, so the deny list keeps the renderer from probing other local services
http:allow-fetch is the only URL-scoped HTTP identifier. tauri-plugin-http validates the URL exactly once, in the fetch command; fetch_send and fetch_read_body operate on an already-validated ResourceId and never consult a scope, so allow/deny blocks on those identifiers are inert and were removed rather than left in place advertising a control that does not exist
The https://* wildcard cannot be removed today: link previews (embeds.ts) fetch arbitrary user-posted URLs by design, and Tauri scopes per command, not per JS caller. Bounded in TypeScript by isPrivateHost/isBlockedForPreview, a 5 s timeout and a 50 KB body cap; the response is regex-scraped for og: tags and never executed
Regression-guarded by tests/unit/capabilities-scope.test.ts; rationale and the follow-up that would remove the wildcard are in docs/plans/tauri-capability-narrowing.md

TLS and Certificate Pinning (TOFU)

Self-signed certificates are supported via Trust-On-First-Use (TOFU) pinning
The WebSocket proxy (ws_proxy) pins the server certificate fingerprint on first connection
The LiveKit proxy (livekit_proxy) reuses the pinned fingerprint from the WS proxy
Certificate mismatch triggers a modal requiring user acknowledgment
Update downloads validate server_url uses https:// and rejects URLs with userinfo

Input Validation

IPC commands validate host format, string lengths, and character allowlists
PTT virtual key codes are validated to the Win32 range (1–254)
LiveKit proxy remote_host is validated against CRLF injection
API client validates host format before constructing URLs
File uploads enforce a MIME type allowlist (images, video, audio, PDF, text)
Error messages from server responses are capped at 200 characters
Notification titles are sanitized (control chars stripped, length capped)

XSS Prevention

All user-generated content is rendered via textContent/setText — never innerHTML
The single innerHTML usage (SVG icons) operates on compile-time constants with a runtime guard
URLs are validated via isSafeUrl (rejects javascript:, data:, vbscript:)
YouTube embeds use sandbox attribute on iframes
image/svg+xml is excluded from safe MIME types for data URIs
GIF media URLs are validated against the trusted Klipy CDN origins
Linkified URLs strip trailing punctuation to prevent misleading destinations

Search and Rate Limiting

Client-side search requests are rate-limited (500ms minimum interval + 300ms debounce)

Known Limitations

Server auto-updates depend on a dedicated pinned minisign/Ed25519 server release key in Server/updater/server_update_public_key.txt and a signed release manifest that binds the shipped binary hash to the release version; Windows Authenticode/SmartScreen code signing is still separate work
CSP connect-src allows https: to any host (necessary for self-hosted server URLs not known at build time). Because of this, narrowing the Tauri http:allow-fetch scope alone would not bound exfiltration from a compromised renderer — the webview's own fetch reaches the same hosts without going through the plugin. Closing that requires narrowing connect-src and moving the link-preview fetch into Rust in the same change

Security Hardening Checklist for Operators

Enable TLS (self-signed is the default; custom certs recommended for production)
Keep invite-only registration enabled (default)
Set a strong admin password
Configure rate limits (defaults are sensible but review for your use case)
Run regular backups via the admin panel
Keep the server updated (admin panel shows available updates)
Firewall: only expose port 8443 (HTTPS); for voice/video also 7880-7881/TCP and 50000-60000/UDP (LiveKit signaling + media — see deployment.md); port 80 only when using ACME
Enable server-wide 2FA requirement once all users have enrolled
Set admin_allowed_cidrs to restrict admin panel access to trusted networks

8.7 KiB Raw Blame History Unescape Escape