Only the latest commit on main is actively maintained. Workspace metadata is
0.8.0, with stabilization work in progress; this is not a promise of a published
or hosted release.
| Version | Supported |
|---|---|
Current main |
Yes |
| Older snapshots/releases | No dedicated backport commitment |
For exploitable vulnerabilities, use the repository's private vulnerability reporting if enabled. If that channel is unavailable, contact the maintainer privately at lorenzo.camuso@gmail.com. Do not publish a working exploit, private content, or credentials in a public issue before coordination.
Include:
- Affected commit and deployment configuration, with secrets removed.
- Attack surface and prerequisites.
- Minimal reproduction using disposable accounts/content.
- Expected versus actual behavior and impact.
- Any suggested mitigation, without changing a live deployment.
Ordinary nonsecurity bugs can use the standard issue templates. Maintainers will assess reports and coordinate fixes/disclosure; no fixed response SLA or bug-bounty payment is promised.
- Login/session — scrypt passwords; opaque random tokens, hash-only persistence, expiry, HttpOnly/SameSite/Secure cookie behavior.
- Mutations — Zod validation, authenticated use cases, exact Origin checks
against
SITE_URLand comma-separatedAPI_ALLOWED_ORIGINS. - Markdown/TOML — bounded fields, safe parser behavior, sanitized HTML, escaped wikilinks, no unsanitized preview/rendering path.
- Public reads — draft, archived, and future content must not leak through detail, list/count, search, tags, backlinks, RSS, or sitemap.
- Media — bounded image uploads, allowed types, validated generated keys, backend-independent rejection of traversal and unsafe input.
- Search/database — repository-owned queries, generated-vector migrations, safe query construction, no browser database access.
- Response headers — API security headers and frontend CSP; verify actual production behavior rather than assuming a proxy preserves it.
Read the Threat model for limits and residual risks.
Use HTTPS and unique strong credentials. Keep database ports private, protect
admin access, restrict exact allowed origins, and maintain tested encrypted
backups. Never commit .env, database dumps, production cookies, credentials,
or private authoring data.
Bounded in-memory rate limits are per-process, reset on restart, and are not distributed denial-of-service protection. Add trusted infrastructure controls for public deployments. A compromised host/database remains outside what application-level validation can contain.
Managed images with saved uses exclusively in the readers audience require
a reader/admin session. Unreferenced images and images with any public-audience
use remain public by key, including draft uses. Draft status alone does not protect
attachments. Already downloaded bytes and issued short-lived signed URLs cannot
be recalled. Do not upload secrets or rely on retroactive revocation.
Revision tables are groundwork, not an audit trail or backup substitute. Scheduled publication depends on the API process and its clock.
The application does not collect analytics and includes no third-party trackers or telemetry SDKs. It stores functional application data, including posts, account identities, password/session hashes, comments, media, and explicit newsletter consent/delivery state when used. Configured SMTP providers receive recipient addresses. Keep reset and newsletter query tokens out of access logs.
Infrastructure can log requests, IP addresses, paths, user agents, and timing. Operators own those systems' retention, access, and redaction policies. External resources intentionally embedded by an author may contact external hosts; do not confuse that with a built-in tracking integration.