# Security Policy
## Supported Versions
| 0.2.x | :white_check_mark: |
| 0.1.x | :white_check_mark: |
## Reporting a Vulnerability
If you discover a security vulnerability in Muxide, please report it responsibly.
### How to Report
**DO NOT** open a public GitHub issue for security vulnerabilities.
Instead, please email: **michaelallenkuykendall@gmail.com**
Include:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
### What to Expect
- **Acknowledgment:** Within 48 hours
- **Initial assessment:** Within 7 days
- **Resolution timeline:** Depends on severity, typically 30-90 days
### Scope
Security issues we care about:
- Memory safety issues (buffer overflows, use-after-free)
- Malformed input causing crashes or hangs
- Resource exhaustion (memory, CPU)
- Output files that could exploit media players
### Out of Scope
- Denial of service via extremely large files (expected behavior)
- Issues in dev-dependencies (proptest, lazy_static)
- Theoretical issues without practical exploit
## Security Design
Muxide is designed with security in mind:
1. **Pure Rust** - Memory safety enforced by Rust’s guarantees
2. **Minimal runtime dependencies** - Limited third-party runtime dependency supply chain
3. **No unsafe code** - All code is safe Rust
4. **Input validation** - All inputs are validated before processing
5. **Bounded operations** - Avoids unbounded allocations from user input where practical
## Acknowledgments
We thank security researchers who help keep Muxide safe. Contributors will be acknowledged here (with permission).