The current repository version is 0.3.0, as declared in pyproject.toml. This policy does not establish a guaranteed security-support period or a backport commitment for any release line. Include the affected version in your report; maintainers will need to determine which releases require a fix.

We take security vulnerabilities seriously. If you discover a security vulnerability in LogXide, please report it privately to allow us to fix it before public disclosure.

Please do NOT report security vulnerabilities through public GitHub issues.

Contact the repository-declared maintainer at freedomzero91@gmail.com (from pyproject.toml). Delivery to this address has not been verified by this policy. Start with a brief description and ask how to share sensitive reproduction data; do not include live credentials or unnecessary personal data.

GitHub private vulnerability reporting enablement has not been verified. A login page at the reporting URL is not confirmation that the feature is enabled. Do not rely on that route unless GitHub actually offers private reporting for this repository after you sign in.

Include the following information:

1. Type of vulnerability: Brief description of the vulnerability type
2. Location: Where in the codebase the vulnerability exists
3. Impact: Potential impact and severity
4. Reproduction: Step-by-step instructions to reproduce the issue
5. Fix suggestion: If you have ideas for fixing the vulnerability
6. Contact: Your preferred contact method for follow-up

There is no guaranteed acknowledgment, assessment, or remediation deadline. Coordinate disclosure and any desired attribution with the maintainer; indicate whether you prefer to remain anonymous. Do not assume receipt until you receive a response.

1. Rust and Python: Rust's safety checks reduce some memory-safety risks; they are not a guarantee that the bindings or dependencies are vulnerability-free.
2. Application input: Messages are not automatically sanitized or redacted. Applications must choose what data to log and how to handle untrusted input.
3. Destinations: File and stream logging need no network destination, but configured HTTP, OTLP, and integration handlers can transmit logs externally.
4. Deployment: Review destination access, file permissions, retention, and dependency updates for your application rather than assuming secure defaults.

While LogXide is designed to be secure, be aware of these potential concerns:

• Risk: Malicious input in log messages could lead to log injection attacks
• Mitigation: Validate and sanitize all log inputs
• Example:

  # Bad: Direct user input
  logger.info(f"User logged in: {user_input}")
  
  # Good: Sanitized input
  logger.info("User logged in: %s", sanitize(user_input))

• Risk: Sensitive information in log messages could be exposed
• Mitigation: Avoid logging sensitive data like passwords, API keys, personal information
• Example:

  # Bad: Logging sensitive data
  logger.info(f"Password: {password}")
  
  # Good: Logging without sensitive data
  logger.info("Authentication successful for user: %s", username)

• Risk: Log files with incorrect permissions could expose sensitive information
• Mitigation: Ensure log files have appropriate permissions (e.g., 600 or 640)
• Note: LogXide doesn't manage file permissions directly; this is the responsibility of the application

• Risk: Excessive logging could lead to disk space exhaustion or performance issues
• Mitigation: Implement rate limiting and log rotation
• Example:

  # Be careful with loops and error conditions
  for item in large_list:
      try:
          process(item)
      except Exception:
          logger.error("Failed to process item: %s", item)  # Could flood logs

• Risk: User-controlled format strings could lead to vulnerabilities
• Mitigation: Never use user input directly as format strings
• Example:

  # Bad: User-controlled format string
  logger.info(user_format_string % data)
  
  # Good: Safe logging
  logger.info("User action: %s", user_action)

import re

def sanitize_log_input(input_string):
    """Remove potentially dangerous characters from log input."""
    # Remove control characters and non-printable characters
    return re.sub(r'[\x00-\x1f\x7f-\x9f]', '', str(input_string))

# Usage
logger.info("User input: %s", sanitize_log_input(user_input))

# Use structured logging to separate data from format
logger.info("User action", extra={
    'user_id': user_id,
    'action': action,
    'timestamp': timestamp
})

# Use appropriate log levels
logger.debug("Detailed debugging info")      # Development only
logger.info("General information")           # Production safe
logger.warning("Warning condition")          # Attention needed
logger.error("Error condition")              # Requires action
logger.critical("Critical condition")        # Immediate action required

Prefer not to log secrets at all. This example creates an application logger and masks case-insensitive password= fields whose values contain no whitespace, including punctuation. It handles literal messages and %-style parameters by rendering record.getMessage() before masking and clearing args. It is not a general secret detector: quoted values containing spaces, other field names, extra fields, exception text, and stack traces need separate treatment.

Use the Python-compatible logxide.handlers.StreamHandler wrapper, not a direct Rust handler or a logger-level filter. Native logger filters receive a dictionary with raw msg and no args, so they cannot safely redact interpolated values. Adding a handler filter selects Python fallback. The IsolatedStreamHandler subclass below copies each record before running filters so other handlers do not see its mutations; the base wrapper does not provide this isolation.

import copy
import re

from logxide import getLogger
from logxide.handlers import StreamHandler


class SensitiveDataFilter:
    def filter(self, record):
        record.msg = re.sub(
            r"(?i)\b(password=)\S+", r"\1***", record.getMessage()
        )
        record.args = ()
        return True


class IsolatedStreamHandler(StreamHandler):
    def handle(self, record):
        return super().handle(copy.copy(record))


logger = getLogger("security.recipe")
handler = IsolatedStreamHandler()
handler.addFilter(SensitiveDataFilter())
logger.addHandler(handler)

Only this handler's output is masked. Replace unfiltered sinks or apply an equivalent policy to every destination, including propagated/root handlers; adding this handler does not protect existing destinations. Use handle(), not emit(), when delivering records directly so filters run. Remove, flush, and close the handler when your application no longer needs it.

The CI workflow (.github/workflows/ci.yml) defines lint/type checks, tests, and cargo audit. This describes configured checks, not a guarantee that a particular run passed or that all security issues are detected. No regular fuzzing program or independent security-audit schedule is established by this policy.

pyproject.toml declares no required Python package dependencies, but the native extension uses Rust dependencies listed in Cargo.toml and pinned in Cargo.lock. Optional integrations add their own dependencies. Review advisories for the full dependency set; a configured cargo audit check is not a comprehensive audit or a claim that dependencies have been independently vetted.

Discuss private handling, disclosure timing, attribution, and any advisory or CVE with the maintainer for the specific report. This policy does not promise a particular disclosure workflow or CVE assignment.

Check repository releases and CHANGELOG.md for published changes. No dedicated security mailing list or security RSS feed is declared here.

The following are manual update commands, not an automatic security-update service. Use the command for your environment, review the resulting version and lockfile, and test compatibility before deployment:

# For a pip-managed environment
pip install --upgrade logxide

# Or use pipenv
pipenv update logxide

# Or use poetry
poetry update logxide

For security-related questions or concerns:

• Maintainer email: freedomzero91@gmail.com, as declared in pyproject.toml; delivery is unverified.
• Encrypted reporting: No PGP key is published in this policy. Agree on a suitable channel before sending sensitive data.

Remember: Security is a shared responsibility. While LogXide is designed to be secure, proper usage and deployment practices are essential for maintaining security in your applications.