Security, licensing, and provenance¶
Security reports that could expose data, execute untrusted code, compromise build or release infrastructure, leak credentials, or provide a practical exploit must use CCB's private vulnerability-reporting channel. Do not disclose an exploitable report in a public issue.
Prepare a private report¶
Include the affected version, commit, platform, threat model, prerequisites, impact, minimal reproduction, and redacted logs. Do not send credentials. If a credential may have leaked, rotate it rather than relying on deletion from Git history.
Ordinary crashes and gameplay bugs without security impact use the normal bug form. Third-party mods and unofficial packages normally belong to their owner, but report any CCB integration boundary clearly.
License and attribution review¶
- Identify the license of every imported code, document, image, sound, font, tile, or generated dataset before copying it.
- Record source repository/URL, exact commit or version, original contributors, modifications, and required notices.
- Preserve compatible notices and commit attribution. A public URL is not a license, and AI-generated text does not erase training or supplied-source provenance obligations.
- Do not publish anomalous contributor strings from automated history parsing; quarantine them for human review.
CCB's repository license files and per-asset notices are authoritative for the material they cover. A Responsible human owns the final provenance and license claim in each pull request.
Privileged changes¶
Workflow permissions, release signing, Pages deployment, security settings, and branch rules require least privilege and human review. Bots cannot approve their own changes. Repository settings are not considered enabled merely because a target YAML file was committed.