From 0e459b3293ce9132ee8bb8324c6e76692e580cc5 Mon Sep 17 00:00:00 2001 From: Paul Nothaft <53005142+the-luap@users.noreply.github.com> Date: Tue, 8 Sep 2026 08:32:54 +0200 Subject: [PATCH] docs: define security support across stable and main (#1351) Co-authored-by: Paul Nothaft --- CONTRIBUTING.md | 5 +- RELEASING.md | 7 ++- SECURITY.md | 129 +++++++++++++++++++++++------------------------- 3 files changed, 70 insertions(+), 71 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 46c9d409..ffc989a7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -172,13 +172,14 @@ PicPeak runs on two long-lived branches: | Branch | Role | What targets it | |---|---|---| | **`main`** | Active development. The next release is being assembled here. | Feature PRs. Most bugfix PRs. | -| **`stable`** | Curated release channel. Production-recommended. | Urgent bugfix backports only — small, surgical PRs that land cleanly without dragging in unrelated changes. | +| **`stable`** | Curated release channel. Production-recommended. | Security fixes and regular bugfix backports, kept small and free of unrelated features. | ### Which branch should my PR target? - **New feature** → target `main`. - **Bugfix that ONLY affects active dev** → target `main`. -- **Bugfix that current stable users need** → open a small PR against `main`, AND a separate small PR against `stable` with the same change. Keep both surgical so each lands cleanly. +- **Bugfix that current stable users need** → target `main`; regular bug fixes are generally backported automatically to `stable`. Maintainers handle conflicts or create a separate focused backport PR when needed. +- **Security vulnerability** → report privately using [SECURITY.md](SECURITY.md). Security fixes are always released on both `stable` and `main`; coordinate any fix with the maintainers before opening a public PR. **Hard rule on PR scope**: bugfix PRs against `stable` must be small enough to backport without conflict. Omnibus PRs (e.g. five unrelated sub-features) are fine for `main`, but never for `stable` — they make the next `main → stable` merge painful and break the "stable is always shippable" invariant. diff --git a/RELEASING.md b/RELEASING.md index 1a1898e8..a61d6178 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -68,13 +68,18 @@ The actual mechanics, in order: ## Hotfix path (backport to current stable) -If a critical bug or security issue affects the current stable and `main` has moved too far for a full promotion to be appropriate, backport just the fix: +Regular bug fixes are generally backported automatically from `main` to `stable`. Keep backports focused on the fix, without unrelated features, and resolve conflicts manually when needed. + +**Security fixes are always released on both `stable` and `main`.** Do not wait for a full promotion to deliver a security update. A fix first applied to `stable` must also be forward-ported to `main`; a fix first applied to `main` must also reach `stable`. See [SECURITY.md](SECURITY.md) for the support policy. + +When a backport needs manual handling: 1. Create a `security/cve-backport-X.Y.Z` or `fix/critical-X.Y.Z` branch off `stable`. 2. Cherry-pick or hand-write the minimal fix. 3. Open a PR to `stable` with the smallest possible diff. 4. After merge, release-please will propose a patch-level stable release (e.g. `v3.55.1`). 5. **Forward-port the fix to `main`** if it isn't already there. Otherwise the next full promotion will reintroduce the bug. +6. For security fixes, verify that the fix has been published through **both** release channels; merging the code is only part of delivery. PR #412 ("backport 18 dependency CVE patches from beta") is a worked example of this path (predates the rename; the mechanics are unchanged). diff --git a/SECURITY.md b/SECURITY.md index 487527fa..f901696d 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,88 +1,81 @@ # Security Policy +## Scope + +This policy covers the PicPeak backend, frontend, all-in-one (AIO) image, optional +ML component, and the Docker images published by the PicPeak project. Other +PicPeak repositories define their own supported versions and release channels. + ## Supported Versions -We release patches for security vulnerabilities. Currently supported versions: +Security support follows the current release channels: -| Version | Supported | -| ------- | ------------------ | -| 2.x.x | :white_check_mark: | -| < 2.0 | :x: | +| Version or channel | Security support | +| --- | --- | +| Latest stable release from `stable` | Supported; security fixes are published through this channel | +| Latest beta release from `main` | Supported; security fixes are published through this channel | +| Superseded stable or beta releases | Upgrade to the latest release in the same channel; older releases are not maintained separately | +| 2.x and earlier | No longer supported | + +See the [latest stable release](https://github.com/PicPeak/picpeak/releases/latest) +and [all releases, including betas](https://github.com/PicPeak/picpeak/releases). +Version numbers differ between channels; each channel receives its own updates. + +### Security fixes and bug backports + +**Security fixes are always released on both `stable` and `main`.** A fix that +lands on one branch must also reach the other branch and be published through +both release channels. Security updates do not wait for the next full +`main`-to-`stable` promotion. + +Regular bug fixes are also generally backported automatically to `stable`. +Backports remain focused on the fix, without pulling in unrelated features. +Maintainers resolve conflicts or handle a backport manually when necessary. + +The [release process](RELEASING.md) describes backports, forward-ports and +publication. Operators must apply the published updates to their installations. ## Reporting a Vulnerability -We take the security of PicPeak seriously. If you have discovered a security vulnerability, please follow these steps: +**Do not report vulnerabilities in public issues, discussions or pull requests.** -### 1. **Do NOT create a public GitHub issue** +Report privately through: -### 2. Report the vulnerability privately by: -- **Preferred:** Use [GitHub Private Vulnerability Reporting](https://github.com/PicPeak/picpeak/security/advisories/new) -- **Alternative:** Email us at **info@picpeak.app** with the details -- Include: - - Description of the vulnerability - - Steps to reproduce - - Potential impact - - Suggested fix (if any) +- [GitHub Private Vulnerability Reporting](https://github.com/PicPeak/picpeak/security/advisories/new) (preferred). +- Email **info@picpeak.app** if you cannot use GitHub's private reporting form. -### 3. You can expect: -- Acknowledgment within 48 hours -- Regular updates on our progress -- Credit in the fix announcement (unless you prefer to remain anonymous) +Include the affected component, version or image tag, deployment method, +reproduction steps, expected impact and any suggested fix. Share only the +information needed to reproduce the problem; remove credentials and personal +data from logs or examples. -## Security Measures +We aim to acknowledge reports within 48 hours. This is a response target, not a +guaranteed service level or a promised resolution time. We will provide progress +updates and coordinate disclosure with the reporter. Reporter credit is optional; +tell us if you prefer to remain anonymous. -PicPeak implements several security measures: +## Deployment Security -### Authentication & Authorization -- JWT-based authentication with secure token storage -- bcrypt password hashing with configurable rounds -- Role-based access control for admin functions -- Session timeout management +Security depends on both the software and its configuration. Operators should: -### Input Validation -- All user inputs are validated and sanitized -- SQL injection prevention through parameterized queries -- XSS protection via Content Security Policy -- File upload restrictions and validation +- Use HTTPS and configure the reverse proxy and trusted proxy settings correctly. +- Use strong credentials and keep deployment secrets private. +- Apply updates for the chosen release channel and restrict unnecessary network access. +- Keep backups and verify that they can be restored. -### Rate Limiting -- API rate limiting to prevent abuse -- Brute force protection on authentication endpoints -- Configurable limits per endpoint - -### Data Protection -- HTTPS enforcement in production -- Secure cookie settings -- CORS configuration -- Sensitive data encryption - -### Infrastructure -- Regular dependency updates -- Security headers (HSTS, X-Frame-Options, etc.) -- Activity logging for audit trails -- Automated backups - -## Best Practices for Deployment - -1. **Always use HTTPS** in production -2. **Change default passwords** immediately -3. **Keep dependencies updated** regularly -4. **Configure firewall rules** appropriately -5. **Monitor logs** for suspicious activity -6. **Backup regularly** and test restoration +See the deployment guides for [HTTPS](https://docs.picpeak.app/deployment/ssl-certificates), +[reverse proxies](https://docs.picpeak.app/deployment/reverse-proxy), +[security settings](https://docs.picpeak.app/guides/admin-settings/security) +and [backup and restore](https://docs.picpeak.app/guides/backup-restore). ## Vulnerability Disclosure -We believe in responsible disclosure. Once a vulnerability is fixed: +We coordinate disclosure with the reporter while preparing fixes. Security fixes +are published through both supported channels. Advisories and release notes +identify affected versions, the fixed version in each channel, the impact and +any required mitigation or upgrade steps. Reporter credit is included with +permission. -1. We'll publish a security advisory -2. Credit researchers (with permission) -3. Detail the impact and mitigation steps -4. Release patches for all supported versions - -## Contact - -- Security issues: Email **info@picpeak.app** or use [GitHub Private Vulnerability Reporting](https://github.com/PicPeak/picpeak/security/advisories/new) -- General support: [GitHub Issues](https://github.com/PicPeak/picpeak/issues) - -Thank you for helping keep PicPeak and its users safe! \ No newline at end of file +For ordinary bugs and support requests, use +[GitHub Issues](https://github.com/PicPeak/picpeak/issues) or +[GitHub Discussions](https://github.com/PicPeak/picpeak/discussions).