If you discover a security vulnerability in schemewasm, please report it responsibly.

1. Do not open a public GitHub issue for security vulnerabilities
2. Email the maintainer directly with:
   • Description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Any suggested fixes (optional)

• Acknowledgment within 48 hours
• Regular updates on progress
• Credit for the discovery (unless you prefer anonymity)
• Public disclosure after a fix is available

Security issues in schemewasm include:

• Memory safety issues in the VM
• Sandbox escape attempts
• Unexpected resource consumption (infinite loops, memory exhaustion)
• Improper error handling that leaks sensitive information

schemewasm runs in a WebAssembly sandbox, which provides:

• Memory isolation between the Scheme program and host
• No filesystem access (unless explicitly provided by the host)
• No network access (unless explicitly provided by the host)

However, the Scheme runtime itself should:

• Not execute infinite loops without eventual termination or host intervention
• Not allocate unbounded memory
• Not crash the Wasm module

If embedding schemewasm in your application:

1. Set resource limits: Configure the host to limit execution time and memory
2. Validate input: Sanitize any user-provided Scheme source code
3. Monitor resources: Track CPU and memory usage during evaluation
4. Use timeouts: Set maximum execution time for eval calls

// Example: Set a timeout for evaluation
const timeoutMs = 5000;
const start = Date.now();
try {
  const result = scheme.eval(source);
  if (Date.now() - start > timeoutMs) {
    throw new Error('Execution timeout');
  }
} catch (e) {
  // Handle error
}

• No true continuations: call/cc is not supported, preventing some attack vectors related to continuations
• Simple GC: The mark-and-sweep GC does not have incremental collection, which may cause pauses during large collections
• Single-threaded: Wasm does not support threading in the current design