Files

51 lines
1.8 KiB
Markdown

# Security Policy
## Supported Versions
The project has not shipped a stable release yet. Until the first release, security fixes apply to the main development branch.
## Reporting A Vulnerability
For now, report vulnerabilities privately to the repository owner through the same channel used to access the private Gitea project.
Do not open a public issue for:
- Credential leaks.
- API key storage flaws.
- Local data exposure.
- Remote code execution.
- Dependency compromise.
## Secret Handling
- Never commit real API keys.
- Never include real API keys in tests, fixtures, screenshots, logs, or documentation examples.
- Prefer OS credential storage for Steam and third-party provider keys.
- Current development builds store the Steam API key in the local SQLite settings database. This is acceptable for the current local MVP but should be revisited before public release.
- If local plaintext storage is temporarily used during early development, it must be clearly marked as temporary and replaced before release.
- Logs must redact API keys and tokens.
## Local Data
The MVP stores user data locally. Treat the following as sensitive:
- Steam API keys.
- Third-party metadata API keys.
- Steam profile identifiers.
- Imported library data.
- Recommendation inputs.
The MVP should not collect telemetry.
## Dependencies
- Prefer maintained packages with clear licenses.
- Validate the terms and maintenance state of any HowLongToBeat-compatible integration before making it core behavior.
- Avoid scraping or unofficial APIs unless their legal and maintenance risks are documented and accepted.
## Release Security
- Attempt self-signing for desktop artifacts where practical.
- Keep release artifacts reproducible enough that a maintainer can rebuild them.
- Do not publish artifacts that contain development credentials or local test data.