English | 中文
This project is currently in active development. No historical versions are supported for security updates.
| Version | Supported |
|---|---|
main branch |
Active development |
dev branch |
Active development |
| Tagged releases | Latest release only |
Please report security vulnerabilities through GitHub's private vulnerability reporting feature:
- Navigate to github.com/xinvxueyuan/lingchu-bot/security/advisories/new.
- Click "Report a vulnerability".
- Fill in the advisory form with the details below.
Alternatively, if you cannot use GitHub's private reporting, open a regular GitHub Issue and tag it with the security label. However, private reporting is strongly preferred to avoid exposing vulnerability details publicly before a fix is available.
If the vulnerability may allow remote code execution, data exfiltration, or authentication bypass, use private vulnerability reporting only. Do not disclose these details in public issues, pull requests, or discussions.
Include the following information in your report:
**Vulnerability title**: [Brief one-line summary]
**Severity**: [Critical / High / Medium / Low]
**Affected component**: [e.g., OneBot V11 adapter, permission system, message store]
**Description**:
[Detailed description of the vulnerability]
**Reproduction steps**:
1. [Step 1]
2. [Step 2]
3. [Step N]
**Expected behavior**: [What should happen]
**Actual behavior**: [What actually happens]
**Impact**: [Who is affected, what an attacker could achieve]
**Environment**:
- OS: [e.g., Windows 11, Ubuntu 24.04]
- Python version: [e.g., 3.13.x]
- Adapter: [e.g., OneBot V11, NapCat]
- Lingchu Bot version/commit: [e.g., v0.0.1 or commit hash]
**Suggested fix** (optional): [If you have a proposed fix]| Stage | Target timeframe |
|---|---|
| Acknowledgment of report | Within 48 hours |
| Initial assessment (severity triage) | Within 5 business days |
| Status update to reporter | Weekly until resolved |
| Fix or mitigation released | Within 30 days for High/Critical; 90 days for Medium/Low |
| Public disclosure (after fix) | Within 14 days after release |
These timeframes are targets, not guarantees. The maintainer will communicate any delays to the reporter.
- Coordinated disclosure: Vulnerabilities are disclosed publicly only after a fix has been released and users have had reasonable time to update.
- Embargo period: Reporters are asked to keep vulnerability details private until the fix is published. The maintainer will coordinate a disclosure date with the reporter.
- Credit: Reporters who follow coordinated disclosure will be credited in the security advisory and release notes, unless they prefer to remain anonymous.
- Public advisory: After the fix is released, a GitHub Security Advisory is published with a CVE assignment (if applicable) and a summary of the vulnerability and fix.
The following are considered in-scope for security reports:
- Authentication or authorization bypass (e.g., superuser escalation, permission bypass)
- Remote code execution through bot commands or API endpoints
- Sensitive data exposure (e.g., configuration secrets, user data leakage)
- Denial of service through crafted messages or API abuse
- Injection vulnerabilities (SQL injection, command injection, path traversal)
The following are out of scope:
- Vulnerabilities in third-party dependencies (report to the upstream project)
- Self-XSS or issues requiring the victim to run malicious commands on their own account
- Theoretical issues without a working proof of concept
- Issues in deprecated/removed adapters (Milky, QQ, OneBot V12)
When deploying Lingchu Bot in production:
- Set
LINGCHU_SUPERUSERSto a minimal set of trusted accounts. - Use
ALEMBIC_STARTUP_CHECK=truein production to enforce schema migration checks. - Disable
FASTAPI_DOCS_URLandFASTAPI_REDOC_URLin production to avoid exposing API documentation. - Run the bot in a container with minimal filesystem permissions.
- Regularly update Python and Node.js dependencies (
uv sync --upgradeandpnpm update).
Build artifacts published from this repository carry SLSA Build L3 provenance. The versioned-build job in 👷-ci-builds.yml generates build provenance for dist/* artifacts using actions/attest-build-provenance@v4.1.0 (SHA-pinned). Provenance binds each artifact to the exact workflow run, source commit, and build environment that produced it.
Consumers and operators can verify the attestation before trusting a downloaded artifact (wheel, sdist, or container image) with the GitHub CLI:
# Verify a downloaded wheel or sdist
gh attestation verify ./nonebot_plugin_lingchu_bot-0.0.1-py3-none-any.whl \
--repository xinvxueyuan/lingchu-bot
# Verify a container image pulled from GHCR
gh attestation verify oci://ghcr.io/xinvxueyuan/lingchu-bot:0.0.1 \
--repository xinvxueyuan/lingchu-botA successful verification prints the attestation source (the 👷-ci-builds.yml workflow run on the releases/** ref) and confirms the artifact was built from the claimed commit. If verification fails, do not install or run the artifact — report it through the private vulnerability reporting channel above.
Additional supply chain notes:
- All third-party GitHub Actions are pinned by 40-character commit SHA with a
# vX.Y.Zcomment; no tag-pinned references are used. - PyPI publishing uses OIDC Trusted Publishing (no long-lived API tokens in repository secrets).
- GHCR pushes use the ephemeral
GITHUB_TOKENscoped topackages: write.