Security is important for a color science library that may be used in production applications processing user input. We take security vulnerabilities seriously and are committed to addressing them promptly and transparently.

A security vulnerability is an issue that could:

• Allow denial of service attacks through resource exhaustion (e.g., crafted inputs causing excessive computation)
• Enable unexpected behavior through numeric overflow or underflow in color conversions
• Expose sensitive information in error messages or logs
• Allow unsafe memory access through incorrect unsafe code usage

Not security vulnerabilities:

• General bugs that don't compromise security
• Feature requests or enhancements
• Performance issues
• Documentation errors
• Color conversion accuracy differences that don't affect security

If you discover a security issue, please bring it to our attention right away!

Please DO NOT file a public issue. Instead, report security vulnerabilities through GitHub's private vulnerability reporting feature.

Your report should include:

• Description of the vulnerability
• Steps to reproduce the issue
• Potential impact of the vulnerability
• Affected versions (if known)
• Suggested fix (if any)
• Your contact information for follow-up questions

After you've submitted your report:

1. Acknowledgment - You'll receive confirmation within 24 hours
2. Investigation - We'll investigate and keep you updated on our findings
3. Resolution - Once we've determined the impact and developed a fix:

• We'll patch the vulnerability
• We'll coordinate disclosure timing with you
• We'll make an announcement to the community if warranted
• You'll be credited for the discovery (unless you prefer to remain anonymous)

• 24 hours - Initial response acknowledging receipt
• 72 hours - Preliminary assessment of impact and severity
• 7 days - Detailed investigation results and remediation plan
• 30 days - Target for patch release (may vary based on complexity)

We follow responsible disclosure practices:

1. Confirm the problem and determine affected versions
2. Audit code to find any similar problems
3. Prepare fixes for all supported versions
4. Coordinate with the reporter on disclosure timing
5. Release patches as soon as possible
6. Publish a security advisory with appropriate details

When contributing to Farg, please follow these security guidelines:

• Never commit sensitive data (API keys, tokens, passwords) to the repository
• Validate and sanitize all user-facing inputs, especially when parsing color strings
• Avoid unsafe code unless absolutely necessary, and document safety invariants
• Handle numeric edge cases (NaN, infinity, overflow) gracefully in color conversions
• Keep dependencies up to date
• Follow the principle of least privilege
• Use secure defaults in configuration

If you have suggestions on how this process could be improved, please submit a pull request or open an issue for discussion.

For urgent security matters that require immediate attention, you can also reach out to the maintainers directly through GitHub.