50 lines
1.6 KiB
Markdown
50 lines
1.6 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.
|
|
- 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.
|