paul/picpeak
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

docs: define security support across stable and main

Browse Source
This commit is contained in:
Paul Nothaft
2026-09-07 23:12:49 +02:00
parent d36585379f
commit 6cc38a6778
3 changed files with 72 additions and 73 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CONTRIBUTING.md
+5 -4
View File
@@ -172,13 +172,14 @@ PicPeak runs on two long-lived branches:
| Branch | Role | What targets it | | Branch | Role | What targets it |
|---|---|---| |---|---|---|
| **`main`** | Active development. The next release is being assembled here. | Feature PRs. Most bugfix PRs. | | **`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? ### Which branch should my PR target?
- **New feature** → target `main`. - **New feature** → target `main`.
- **Bugfix that ONLY affects active dev** → 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. **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.
@@ -196,6 +197,6 @@ See [RELEASING.md](RELEASING.md) for the full operational doc (promotion criteri
- Create an [issue](https://github.com/PicPeak/picpeak/issues) for bugs or features - Create an [issue](https://github.com/PicPeak/picpeak/issues) for bugs or features
- Join [discussions](https://github.com/PicPeak/picpeak/discussions) for questions - Join [discussions](https://github.com/PicPeak/picpeak/discussions) for questions
- Security issues: Open a [security issue](https://github.com/PicPeak/picpeak/issues/new?labels=security) on GitHub - Security vulnerabilities: Follow the [security policy](SECURITY.md) and use [private vulnerability reporting](https://github.com/PicPeak/picpeak/security/advisories/new)
Thank you for contributing! 🎉 Thank you for contributing! 🎉
RELEASING.md
+6 -1
View File
@@ -68,13 +68,18 @@ The actual mechanics, in order:
## Hotfix path (backport to current stable) ## 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`. 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. 2. Cherry-pick or hand-write the minimal fix.
3. Open a PR to `stable` with the smallest possible diff. 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`). 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. 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). PR #412 ("backport 18 dependency CVE patches from beta") is a worked example of this path (predates the rename; the mechanics are unchanged).
SECURITY.md
+61 -68
View File
@@ -1,88 +1,81 @@
# Security Policy # 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 ## Supported Versions
We release patches for security vulnerabilities. Currently supported versions: Security support follows the current release channels:
| Version | Supported | | Version or channel | Security support |
| ------- | ------------------ | | --- | --- |
| 2.x.x | :white_check_mark: | | Latest stable release from `stable` | Supported; security fixes are published through this channel |
| < 2.0 | :x: | | 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 ## 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: - [GitHub Private Vulnerability Reporting](https://github.com/PicPeak/picpeak/security/advisories/new) (preferred).
- **Preferred:** Use [GitHub Private Vulnerability Reporting](https://github.com/PicPeak/picpeak/security/advisories/new) - Email **[email protected]** if you cannot use GitHub's private reporting form.
- **Alternative:** Email us at **[email protected]** with the details
- Include:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
### 3. You can expect: Include the affected component, version or image tag, deployment method,
- Acknowledgment within 48 hours reproduction steps, expected impact and any suggested fix. Share only the
- Regular updates on our progress information needed to reproduce the problem; remove credentials and personal
- Credit in the fix announcement (unless you prefer to remain anonymous) 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 Security depends on both the software and its configuration. Operators should:
- JWT-based authentication with secure token storage
- bcrypt password hashing with configurable rounds
- Role-based access control for admin functions
- Session timeout management
### Input Validation - Use HTTPS and configure the reverse proxy and trusted proxy settings correctly.
- All user inputs are validated and sanitized - Use strong credentials and keep deployment secrets private.
- SQL injection prevention through parameterized queries - Apply updates for the chosen release channel and restrict unnecessary network access.
- XSS protection via Content Security Policy - Keep backups and verify that they can be restored.
- File upload restrictions and validation
### Rate Limiting See the deployment guides for [HTTPS](https://docs.picpeak.app/deployment/ssl-certificates),
- API rate limiting to prevent abuse [reverse proxies](https://docs.picpeak.app/deployment/reverse-proxy),
- Brute force protection on authentication endpoints [security settings](https://docs.picpeak.app/guides/admin-settings/security)
- Configurable limits per endpoint and [backup and restore](https://docs.picpeak.app/guides/backup-restore).
### 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
## Vulnerability Disclosure ## 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 For ordinary bugs and support requests, use
2. Credit researchers (with permission) [GitHub Issues](https://github.com/PicPeak/picpeak/issues) or
3. Detail the impact and mitigation steps [GitHub Discussions](https://github.com/PicPeak/picpeak/discussions).
4. Release patches for all supported versions
## Contact
- Security issues: Email **[email protected]** 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!