# Security Policy
## Reporting a Vulnerability
If you discover a security vulnerability in Kelora, please report it privately:
- **Email:** security@dirk-loss.de
- **Subject line:** "Kelora Security: [brief description]"
- **Include:** Version number, description of the issue, and steps to reproduce
**Please do not open public GitHub issues for security vulnerabilities.**
### What to Expect
Kelora is maintained by a single developer on a best-effort basis. Security reports are taken seriously, but response times reflect this reality:
- **Acknowledgment:** Within 1 week
- **Assessment:** Within 2-4 weeks depending on complexity
- **Resolution:** Timelines depend on severity and complexity; critical issues will be prioritized
- **Disclosure:** After a fix is released, the vulnerability will be documented in the changelog
For critical vulnerabilities requiring immediate action, please clearly mark them as such in your report.
## Supported Versions
Kelora is currently in active development. Security updates are provided for the latest release only.
As a 0.x release, Kelora does not guarantee backports to older versions. Users should stay up to date with the latest release.
## Security Measures
Kelora implements multiple layers of security controls to ensure safe operation:
### Automated Testing
- **Hundreds of test functions** covering core functionality, parsers, and edge cases
- **Integration tests** validating end-to-end behavior
- **CI enforcement** on every commit (formatting, linting, tests)
### Dependency Security
- **cargo-audit** runs via `just audit` to detect known vulnerabilities in dependencies
- **cargo-deny** enforces dependency policies via `just deny`:
- License compliance (MIT, Apache-2.0, BSD, etc.)
- Advisory checking against RustSec database
- Duplicate dependency detection
- Source verification (crates.io only)
### Code Safety
- **Minimal unsafe code:** Only 2 `unsafe` blocks in the entire codebase (all other unsafe code is forbidden)
- `src/decompression.rs` - Manual `Send` implementation for `DecompressionReader` (all variants contain `Send` types)
- `src/readers.rs` - Manual `Send` implementation for `PeekableLineReader` (underlying reader is `Send`)
- **Clippy enforcement** with warnings-as-errors (`-D warnings`) blocks any lints from merging
- **Memory safety:** Rust's ownership system prevents buffer overflows, use-after-free, and data races
### Development Process
Kelora is developed using AI-generated code (Claude, GPT-5). Validated through automated testing, not manual review. Quality assurance includes:
- Comprehensive automated tests for all features
- Functional validation through testing and usage
- Continuous integration checks on every change
- Security tooling (audit, deny) integrated into development workflow
### CI/CD Pipeline
Every commit and pull request must pass:
- `cargo fmt --all --check` (code formatting)
- `cargo clippy --all-targets --all-features -- -D warnings` (static analysis)
- `cargo test --all-features` (all tests must pass)
## Known Security Advisories
Kelora currently ignores one advisory in `deny.toml`:
- **RUSTSEC-2024-0384** - `instant` crate is unmaintained
- **Reason:** Transitive dependency via `chrono`, acceptable risk for now
- **Mitigation:** Monitoring for upstream fixes or alternatives
- **Impact:** No known exploits affecting Kelora's use case
All other advisories result in build failures.
## Threat Model
### What Kelora Does
- Processes log files locally on your machine
- Executes user-provided Rhai scripts against log data
- Reads from files, stdin, and gzip/zstd compressed streams
- Writes to stdout or files
### What Kelora Does NOT Do
- No network access (no outbound connections)
- No privilege escalation
- No persistent daemons or background processes
- No telemetry or data collection
- No modification of input files (read-only)
### Security Boundaries
**Trusted inputs:**
- Rhai scripts provided by the user (via `--exec`, `--filter`, `-E`)
- Configuration files (`.kelora.ini`, aliases)
**Untrusted inputs:**
- Log file contents (may contain attacker-controlled data)
- Standard input streams
**Protections:**
- Log data is parsed and processed but cannot execute code
- Rhai scripts run in a sandboxed environment with no filesystem write access by default
- File writes require explicit `--allow-fs-write` flag (enables `append_file()` function)
- Standard output redirection (`>`, `>>`) is controlled by the shell, not Kelora
- Malformed log entries are skipped with diagnostics (default resilient mode)
### Known Limitations
1. **Rhai script safety:** User-provided scripts execute with the same privileges as the Kelora process. Users should review scripts from untrusted sources.
2. **Resource exhaustion:** Processing very large files or complex scripts can consume significant CPU and memory. Use `--parallel` for large archives and monitor resource usage.
3. **Regex complexity:** User-provided regex patterns in scripts could be computationally expensive on crafted input. The regex engine (Rust `regex` crate) has DoS protections, but extremely complex patterns may still be slow.
## Security Best Practices for Users
### Running Kelora Safely
1. **Review scripts before execution:** If using scripts from external sources, review them first
2. **Use `--strict` mode cautiously:** Strict mode fails on parse errors; default resilient mode is safer for production
3. **Limit resource usage:** Use `ulimit` or containerization when processing untrusted files
4. **Keep Kelora updated:** Security fixes are only applied to the latest version
5. **Validate file sources:** Only process log files from trusted sources when handling sensitive data
### Example: Safe Processing of Untrusted Logs
```bash
# Process with resource limits (Linux/macOS)
ulimit -v 2000000 # 2GB virtual memory limit
# With timeout (Linux with GNU coreutils)
timeout 60s kelora -j untrusted.jsonl --filter 'e.level == "ERROR"'
# Or use shell job control (cross-platform)
kelora -j untrusted.jsonl --filter 'e.level == "ERROR"' &
PID=$!
sleep 60 && kill $PID 2>/dev/null
# Use strict mode to fail fast on malformed input
kelora -j logs.jsonl --strict --filter 'e.valid_field'
```
## Dependency Policy
Kelora only uses dependencies from crates.io with the following criteria:
- **License:** Must be compatible with MIT and not impose additional restrictions (no copyleft licenses like GPL)
- Allowed: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, Zlib, Unlicense, CC0-1.0, MPL-2.0, Unicode-3.0, BSL-1.0
- **Source:** Must come from crates.io (no git dependencies)
- **Maintenance:** Prefer actively maintained crates
- **Security:** No known high-severity vulnerabilities (enforced by cargo-audit)
- **Scope:** Only well-established crates for critical functions (parsing, crypto, compression)
See `deny.toml` for the complete dependency policy configuration and enforcement rules.
## Security Audit History
No formal third-party security audits have been conducted. The project relies on:
- Automated tooling (cargo-audit, cargo-deny, clippy)
- Rust's memory safety guarantees
- Comprehensive test coverage
- Community review (open source)
## Contact
For security concerns, contact: security@dirk-loss.de
For general issues: https://github.com/dloss/kelora/issues
