Please do not open a public issue for a security vulnerability. Use GitHub's private reporting instead:
- Go to the Security tab.
- Click Report a vulnerability.
- Describe the issue and, if possible, how to reproduce it.
ravel is pre-1.0 and tracks a single moving line: the latest commit on
main. There is no older release branch receiving backports.
ravel is a testing/simulation harness, not a production runtime component — it links into test binaries, not into the system under test's shipped artifact. Realistic concerns:
- Out-of-bounds access, integer overflow, or UB reachable from public API inputs (seeds, fault specs, channel names a caller controls).
- The C ABI (
include/ravel/ravel.h) never letting a C++ exception cross into a C caller (undefined behavior on ABI boundaries) — every function there must catch internally and return a status code instead. All four exported functions were audited for this (includingcreate, whose constructor can throw even understd::nothrow, anddestroy); a test covers null handles. VirtualRng(include/ravel/rng.hpp) is not cryptographically secure and must never be used as a source of randomness for anything security-sensitive (tokens, keys, nonces) in code that happens to also use ravel for testing. It is a fast, portable, reproducible PRNG only.
- Fault injection is opt-in and local.
FaultSpecon aChannelonly affects messages routed through ravel's own virtualChannel/network types inside aSimulationprocess — it has no ability to reach a real socket, a real disk, or a process ravel didn't spawn. There is no "target a remote host" mode; the library has no code path that opens a real network connection. - The only real files ravel touches are the ones you point it at. When
SimulationOptions::trace_diris set it creates that directory and writesravel-seed-<number>.*files (traces, choice lists) into it; file names contain only a number, never caller-supplied text.read_choicesparses a stream the caller opens. It sizes nothing from the file's own counts, so a hostile or corrupt file can only make it throw, and replaying any list is safe because every value is clamped to the bound of the draw it answers. Nothing else in the library opens a file. - No dynamic code loading, no eval of external input. Simulation scenarios are C++ code the caller compiles and links, not a scripting format ravel parses — so there is no scenario-file injection surface to worry about.
- If a future version adds real syscall/process virtualization (v1 stretch scope), that boundary gets its own security-review pass and its own entry here before it ships — it is not part of the v0.1 surface today.