Do not open a public GitHub issue for security vulnerabilities.

If you discover a security issue, please email the maintainer privately at:

security@questmate.dev

Include:

1. Description of the vulnerability
2. Steps to reproduce (if applicable)
3. Potential impact (e.g., data leak, code execution, privilege escalation)
4. Suggested fix (optional)
5. Your name / attribution preference (optional)

We will:

• Acknowledge receipt within 48 hours
• Work on a fix in a private branch
• Credit you in the security advisory (unless you prefer anonymity)
• Release a patched version within 7 days of confirmation (or explain delays)

Security updates are released as patch versions (e.g., 1.0.1, 1.0.2). We backport critical fixes to the previous major version for up to one year.

• ADB command injection - User input is never passed directly to adb. Commands are built with explicit arguments, not shell interpolation.
• Arbitrary code execution from JSON - Catalog JSON is parsed as data only, never eval'd or dynamically imported.
• Privilege escalation - QuestMate runs as the user (never sudo without explicit request). Udev rules grant group-level access, not root.
• Man-in-the-middle attacks - HTTPS only for catalog/download sources. SHA256 checksums verified where possible.

• Local attacks - If an attacker has shell access to your PC, they can install malicious apps to your Quest via ADB regardless.
• Malicious Quest apps - QuestMate is a sideloader, not a sandbox. An app installed via QuestMate runs with full Quest privileges, same as any other sideloaded app.
• Meta/Oculus policy violations - Sideloading Quest games is your responsibility. QuestMate does not circumvent any technical protections.

QuestMate depends on:

• httpx - HTTP client (supply chain risk: vendored in .deb where possible)
• PyGObject - GTK4 bindings (system package, maintained by GNOME)
• android-tools-adb - ADB binary (system package, maintained by Android Open Source Project)

We pin dependency versions in requirements.txt to prevent surprise breaking changes. pip install -r requirements-dev.txt includes tools for security auditing.

If a critical security patch is released for a dependency, we will:

1. Test the new version in a feature branch
2. Update requirements.txt
3. Release a new patch version within 24 hours (note: current early dev status may affect timing)

All code changes:

• Require type hints (static analysis catches type confusions)
• Include unit tests (logic bugs are caught early)
• Pass ruff linting (no bare except, no dangerous patterns)
• Pass mypy type checking (prevents Pyright-detectable vulnerabilities)

Security-sensitive code paths (ADB, downloads, file I/O) must have:

• ≥ 80% test coverage
• Explicit error handling (no silent failures)
• Clear docstrings explaining invariants

If a vulnerability is discovered post-release:

1. Triage - We determine severity (Critical / High / Medium / Low)
2. Fix - Write and test a patch in a private branch
3. Release - Publish a new patch version with a security advisory
4. Communicate - GitHub Security Advisory, README note, social media (for Critical)

Critical issues (remote code execution, privilege escalation) get priority.

If you have security questions that aren't vulnerability reports, you can:

• Open a GitHub Discussion tagged security
• Check the ROADMAP.md for planned security features
• Review CONTRIBUTING.md for development best practices

Last updated: April 2026