mirror of
https://github.com/getnora-io/nora.git
synced 2026-04-12 10:20:32 +00:00
DevITWay | Pavel Volkov
bb125db074
* fix: remove unwrap() from production code, improve error handling - Replace unwrap() with proper error handling in npm, mirror, validation - Add input validation to cargo registry (crate name + version) - Improve expect() messages with descriptive context in metrics, rate_limit - Remove unnecessary clone() in error.rs, docker.rs, npm.rs, dashboard_metrics - Add #![deny(clippy::unwrap_used)] to prevent future unwrap in prod code - Add let-else pattern for safer null checks in validation.rs * docs: update SECURITY.md — add 0.3.x to supported versions * security: forbid unsafe code at crate level Add #![forbid(unsafe_code)] to both lib.rs and main.rs. NORA has zero unsafe blocks — this prevents future additions without removing the forbid attribute (stronger than deny). * build: add rust-toolchain.toml, Dockerfile HEALTHCHECK - Pin toolchain to stable with clippy + rustfmt components - Add Docker HEALTHCHECK for standalone deployments (wget /health) * test: add Go proxy and Raw registry integration tests Go proxy tests: list, .info, .mod, @latest, path traversal, 404 Raw registry tests: upload/download, HEAD, 404, path traversal, overwrite, delete, binary data (10KB)
57 lines
1.7 KiB
Markdown
57 lines
1.7 KiB
Markdown
# Security Policy
|
|
|
|
## Supported Versions
|
|
|
|
| Version | Supported |
|
|
| ------- | ------------------ |
|
|
| 0.3.x | :white_check_mark: |
|
|
| 0.2.x | :white_check_mark: |
|
|
| < 0.2 | :x: |
|
|
|
|
## Reporting a Vulnerability
|
|
|
|
**Please do not report security vulnerabilities through public GitHub issues.**
|
|
|
|
Instead, please report them via:
|
|
|
|
1. **Email:** devitway@gmail.com
|
|
2. **Telegram:** [@DevITWay](https://t.me/DevITWay) (private message)
|
|
|
|
### What to Include
|
|
|
|
- Type of vulnerability
|
|
- Steps to reproduce
|
|
- Potential impact
|
|
- Suggested fix (if any)
|
|
|
|
### Response Timeline
|
|
|
|
- **Initial response:** within 48 hours
|
|
- **Status update:** within 7 days
|
|
- **Fix timeline:** depends on severity
|
|
|
|
### Severity Levels
|
|
|
|
| Severity | Description | Response |
|
|
|----------|-------------|----------|
|
|
| Critical | Remote code execution, auth bypass | Immediate fix |
|
|
| High | Data exposure, privilege escalation | Fix within 7 days |
|
|
| Medium | Limited impact vulnerabilities | Fix in next release |
|
|
| Low | Minor issues | Scheduled fix |
|
|
|
|
## Security Best Practices
|
|
|
|
When deploying NORA:
|
|
|
|
1. **Enable authentication** - Set `NORA_AUTH_ENABLED=true`
|
|
2. **Use HTTPS** - Put NORA behind a reverse proxy with TLS
|
|
3. **Limit network access** - Use firewall rules
|
|
4. **Regular updates** - Keep NORA updated to latest version
|
|
5. **Secure credentials** - Use strong passwords, rotate tokens
|
|
|
|
## Acknowledgments
|
|
|
|
We appreciate responsible disclosure and will acknowledge security researchers who report valid vulnerabilities in our release notes and CHANGELOG, unless the reporter requests anonymity.
|
|
|
|
If you have previously reported a vulnerability and would like to be credited, please let us know.
|