Kwker
Try it
Menu
Security

Security policy

Kwker runs native SIMD code inside your process. Memory safety and correct results are the first requirement of every release.

Supported versions

Kwker is pre-1.0. Security fixes go into the newest minor version as a patch release (0.1.x: the next 0.1 patch). Older minor versions are not patched. Upgrading within a minor version never breaks callers (see the compatibility promise), so a fix is always a drop-in upgrade.

Reporting a vulnerability

Report a suspected vulnerability privately by email to mail@kwker.io. Please do not report it in public.

A useful report names:

  • the entry point (Rust API, C ABI, a language binding, the PyTorch or JAX operators) and the engine in use (AVX-512, AVX2, SSE4.2, NEON, SVE or portable; python -m kwker doctor prints it),
  • the key type, the input size and a way to produce the input (a seed, a generator or the data),
  • what happens (crash, out-of-bounds access, wrong result, hang) and, if you have one, a sanitizer report.

Response targets

  • Acknowledgement within 7 days.
  • Assessment within 14 days.
  • A fix or mitigation for confirmed memory-safety issues within 30 days.

Reporters are credited in the release notes unless they ask not to be.

Scope

In scope: memory safety of the C++ SIMD engines and the C ABI (out-of-bounds reads or writes, use-after-free, data races in the parallel sorts), incorrect results a caller cannot detect (keys lost or duplicated), and unbounded resource use (memory beyond the documented scratch limits, non-termination) on any input.

How Kwker is tested

Every engine runs the same correctness suite and differential fuzzing against reference sorts, with AddressSanitizer, UndefinedBehaviorSanitizer and ThreadSanitizer builds and coverage-guided fuzzing (libFuzzer). Results are compared bit for bit across engines. See Behavior for the rules every engine follows.