29 lines
1.4 KiB
Markdown
29 lines
1.4 KiB
Markdown
# Security
|
|
|
|
## Reporting a vulnerability
|
|
|
|
Do not post passwords, access tokens, encryption keys, database exports, backup
|
|
files or live exploit details in public issues, discussions or container logs.
|
|
Use the repository hosting platform's private vulnerability-reporting feature
|
|
if the release owner has enabled it. Otherwise contact the maintainer privately
|
|
through the platform where you obtained this release before sending sensitive
|
|
details. This repository does not currently advertise a dedicated reporting
|
|
address; the release owner must establish one before a broad public launch.
|
|
|
|
Include the image tag/digest, affected version, a minimal reproduction using
|
|
synthetic data, and the security impact. Remove deployment credentials and
|
|
personal data from attachments. Do not test against systems you do not own or
|
|
have permission to assess.
|
|
|
|
## Deployment precautions
|
|
|
|
Follow [the public installation guide](docs/PUBLIC_RELEASE.md): use HTTPS for
|
|
public access, independent random secrets, a protected persistent data volume,
|
|
and the exact browser-facing origin. Keep the original signing/encryption keys
|
|
when upgrading. Do not disable origin checks or run as root to work around a
|
|
deployment failure.
|
|
|
|
Use a reviewed immutable release image and retain a tested backup. Check the
|
|
release's declared architecture support and migration notes. The project has
|
|
not declared an LTS support window or a guaranteed security-response SLA.
|