| Version | Supported |
|---|---|
| 0.x | Yes (current dev) |
If you discover a security vulnerability in NLPL, please report it responsibly.
Do NOT open a public issue for security vulnerabilities.
Instead, please email: erichakansson84@gmail.com
Include the following in your report:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
- Acknowledgement: Within 48 hours
- Initial assessment: Within 7 days
- Fix or mitigation: Within 30 days for critical issues
- We will coordinate disclosure timing with the reporter
- We will credit reporters in the security advisory (unless they prefer anonymity)
- We aim to release a fix before or simultaneously with public disclosure
NLPL is a general-purpose programming language. When writing NLPL programs that handle untrusted input, follow these security practices:
- Validate all external input at system boundaries
- Use the type system to enforce data constraints
- NLPL's borrow checker prevents use-after-move and dangling references
- Smart pointers (Rc, Arc) manage reference-counted memory automatically
- The runtime enforces borrow rules at execution time
- Foreign function calls (
load library,extern function) bypass NLPL's safety guarantees - Validate all data crossing the FFI boundary
- Prefer NLPL-native implementations where possible
- Use the
cryptostdlib module for cryptographic operations - Do not implement custom cryptographic algorithms in application code
This policy covers:
- The NLPL interpreter and compiler (
src/nlpl/) - The standard library (
src/nlpl/stdlib/) - The build system and CI infrastructure
- Official documentation and examples
Out of scope:
- Third-party libraries or tools not maintained by the NLPL project
- Vulnerabilities in user-written NLPL programs