Security Policy

The SUB project takes security seriously. This document describes how to report vulnerabilities and which versions receive security updates.

Reporting a Vulnerability

Do not open a public GitHub issue for security vulnerabilities.

If you discover a security vulnerability in SUB, please report it responsibly:

1. Email the project maintainer directly via GitHub.
2. Include a description of the vulnerability, steps to reproduce, and the affected version(s).
3. If possible, include a proof-of-concept or minimal reproducing example.

What to Report

The following are considered security vulnerabilities:

• Buffer overflows or memory corruption in subc or subi
• Arbitrary code execution through crafted .sb files
• Path traversal in file operations
• Command injection through builtins (e.g., net_fetch, net_post)
• Denial of service through resource exhaustion (infinite loops in stdlib, unbounded allocation)
• Supply chain attacks (compromised build artifacts, tampered releases)

Out of Scope

The following are not considered security vulnerabilities:

• Bugs in transpiled output that don't affect the SUB toolchain itself
• Denial of service from intentionally malicious SUB programs (the interpreter/compiler is not a sandbox)
• Theoretical vulnerabilities without a proof of concept

Supported Versions

Security patches are provided for the following versions:

Verification

All release artifacts are signed and checksummed. To verify your download:

# Download the checksums file
wget https://github.com/subhobhai943/sub-lang/releases/latest/download/checksums-sha256.txt

# Verify
sha256sum -c checksums-sha256.txt --ignore-missing

If you suspect a release has been tampered with, report it immediately as a security vulnerability.

Disclosure Policy

We follow a coordinated disclosure process:

1. Report received — acknowledged within 48 hours
2. Investigation — we confirm the vulnerability and assess severity
3. Fix developed — a patch is prepared and tested
4. Release — the fix is published in a new release
5. Disclosure — the vulnerability is publicly disclosed with credit to the reporter (unless they prefer anonymity)

Contact

For security inquiries, contact the maintainer via GitHub. For non-security questions, use GitHub Discussions or open a regular issue.