We actively support the following versions of batless with security updates:

We take security vulnerabilities seriously. If you discover a security issue in batless, please follow these steps:

1. Do NOT create a public issue for security vulnerabilities
2. Email security concerns to: [security@batless.dev] (or create a private security advisory on GitHub)
3. Include the following information:
   • Description of the vulnerability
   • Steps to reproduce the issue
   • Potential impact
   • Any suggested fixes (if available)

• Acknowledgment: We will acknowledge receipt of your report within 48 hours
• Initial Assessment: We will provide an initial assessment within 5 business days
• Updates: We will keep you informed of our progress
• Resolution: We aim to resolve critical vulnerabilities within 30 days

This security policy covers:

• The batless CLI application
• The batless library (crate)
• Build and release processes
• Dependencies and supply chain

• batless processes files locally and does not send data to external services
• File content is streamed and not stored permanently
• No network connections are made during normal operation

• We regularly audit dependencies for known vulnerabilities
• Dependencies are kept up to date with security patches
• We use cargo audit in our CI/CD pipeline

• File paths are validated to prevent directory traversal
• Input limits are enforced to prevent resource exhaustion
• Malformed files are handled gracefully without crashes

1. Large Files: While batless uses streaming, extremely large files could still impact system resources
2. Malformed Files: Syntect (our syntax highlighting library) is generally robust, but malformed files might cause parsing issues
3. File Permissions: batless respects system file permissions and will not attempt to read files without proper access

1. Verify Downloads: Always download batless from official sources
2. Check Signatures: Verify release signatures when available
3. Update Regularly: Keep batless updated to the latest version
4. Limit File Access: Run batless with minimal necessary file permissions
5. Validate Output: Be cautious when processing output in automated systems

Once a security vulnerability is reported and confirmed:

1. Day 0: Vulnerability reported
2. Day 1-2: Acknowledgment and initial triage
3. Day 3-7: Detailed analysis and fix development
4. Day 8-14: Testing and validation of fix
5. Day 15-30: Release of patched version
6. Day 30+: Public disclosure (coordinated with reporter)

We recognize security researchers who help improve batless security:

• [Your name could be here!]

• Security Email: [INSERT EMAIL]
• PGP Key: [INSERT PGP KEY ID if available]
• GitHub Security Advisories: Use GitHub's private vulnerability reporting feature

This security policy is provided in good faith. We reserve the right to modify this policy at any time. Security researchers acting in good faith under this policy will not face legal action from the batless project.

Thank you for helping keep batless secure! 🔒