Please DO NOT open a public issue for security vulnerabilities.

Send security vulnerabilities to: paski@paski.dev

Include in your report:

• Description of the vulnerability
• Steps to reproduce
• Affected versions
• Potential impact
• Suggested fix (if you have one)

• Acknowledgment: Within 48 hours
• Initial Assessment: Within 5 business days
• Status Updates: Every 7 days until resolved
• Public Disclosure: After fix is released (coordinated disclosure)

We follow responsible disclosure practices:

1. You report the vulnerability privately
2. We confirm and investigate
3. We develop and test a fix
4. We release the fix
5. We publicly disclose (with credit to you if desired)
6. You can publish your findings after disclosure

• ✅ Credentials stored in OS keychain (not plaintext)
• ✅ Support for SSH keys and tokens
• ✅ OAuth flows for GitHub/GitLab/Bitbucket
• ❌ Never logs credentials
• ❌ Never transmits credentials except to authenticated endpoints

• Snapshots are local-only by default
• Sensitive files (.env, credentials) excluded from snapshots
• Snapshots encrypted at rest (optional, configurable)
• Auto-cleanup prevents unlimited disk usage

• ✅ TLS for all external communications
• ✅ Certificate pinning for critical endpoints
• ✅ Webhook signature verification
• ❌ No telemetry or tracking by default

• AI analysis runs locally by default
• Premium tier analysis: data encrypted in transit
• No code sent to third parties without explicit consent
• You can review analysis queries before sending

We provide security updates for:

Once 1.0 is released:

Torii inherits security properties of git2-rs and libgit2:

• SSH key management follows git standards
• HTTPS uses system certificate stores
• Git hooks are disabled by default (security risk)

Important: Snapshots may contain:

• Uncommitted code
• API keys in files (if not in .toriignore)
• Passwords in config files
• Personal data in test files

Recommendation:

• Use .toriignore properly
• Enable snapshot encryption
• Review snapshot contents before sharing

When syncing to mirrors:

• Credentials for each platform stored separately
• Sync operations use platform APIs (not git protocol)
• Webhook secrets rotated periodically
• Failed auth attempts logged and rate-limited

Vulnerabilities in the git hosting providers themselves (GitHub, GitLab, Codeberg, etc.) are out of scope for torii — torii is just a client. We list noteworthy ones here so users running self-hosted instances know to patch.

A server-side bug in GitHub's babeld / gitauth / gitrpcd proxy chain let any authenticated user inject semicolons into a git push -o option value, override an internal X-Stat header, and gain remote code execution on GitHub's backend. CVSS 8.8.

• Not a torii bug. Identical to using stock git push -o against the same server. torii's transport (rustls / russh) only ferries the bytes the user typed; the server mis-parses them.
• GitHub.com: patched by GitHub on 2026-03-04 (~2h after report).
• GitHub Enterprise Server: upgrade to 3.14.25 / 3.15.20 / 3.16.16 / 3.17.13 / 3.18.7 / 3.19.4 or newer.
• No torii action required.

References: NVD CVE-2026-3854, Wiz writeup, GitHub blog.

# ✅ Good: Use SSH keys
torii config --auth-method ssh

# ✅ Good: Use tokens with minimal scope
torii config --token <token> --scope "repo:read,repo:write"

# ❌ Bad: Store credentials in plaintext
# Never do: git config credential.helper store

# .torii/config.toml

[snapshots]
enabled = true
encrypt = true  # ✅ Recommended
exclude_patterns = [
    "**/.env*",
    "**/credentials.json",
    "**/*_rsa",
    "**/*.key",
]

[mirrors]
# ✅ Good: Use deploy keys (read-only on mirrors)
[[mirrors.github]]
url = "https://github.com/user/repo"
auth_method = "deploy_key"
permissions = "read"

# ⚠️ Caution: Personal access tokens have broad scope
# Use with minimal permissions only

Before submitting code:

• No hardcoded credentials or API keys
• No use of unwrap() on user input
• Input validation for all external data
• Proper error handling (no panic on bad input)
• Dependency review (cargo audit)
• No unsafe blocks without justification
• Sensitive data sanitized from logs

We welcome security audits of Torii. If you're conducting an audit:

1. Email paski@paski.dev with your intent
2. We'll provide guidance on scope and priorities
3. You can request clarification on implementation details
4. Report findings according to responsible disclosure above

Security researchers who have responsibly disclosed vulnerabilities:

No reports yet - be the first!

• Security Issues: paski@paski.dev
• General Contact: paski@paski.dev
• PGP Key: [To be published]

Last Updated: 2026-04-09