Files

T

kingchenc 12681e4b1b C ABI: full example suite + docs & About coverage (#224 )

Stacked on #222 (base `feat/c-abi-hub`), so the diff is just the additions on top of the hub foundation — no merge of #222 required.

## What this adds

**Examples — full parity with rust/python/node (`examples/c/`)**
- `streaming.c` upgraded to the multi-indicator (SMA/EMA/RSI/MACD + signals) demo
- `backtest.c`, `multi_timeframe.c` (manual time-bucket resampling), `parallel_assets.c` (serial vs OpenMP fan-out, one handle per asset)
- three educational strategies: `strategy_rsi_mean_reversion.c`, `strategy_macd_adx.c`, `strategy_bollinger_squeeze.c`
- two network examples shelling out to `curl`: `fetch_btcusdt.c`, `live_binance.c` (REST poll)
- two header-only helpers (`wickra_csv.h`, `wickra_strategy.h`) since the C ABI ships no IO layer
- CMake builds all 11; the 9 offline ones run under `ctest` on 3 OS; the network two are built-only

**Docs & metadata — surface the C ABI everywhere it was missing**
- ARCHITECTURE diagram + crate table, SECURITY + THREAT_MODEL (the C ABI as the sole `unsafe` FFI surface), the three binding package READMEs, issue/PR templates, CHANGELOG, and the GitHub About template (live About + org description updated too)

**Cleanup**
- removed all references to the private generator tooling from public files (`bindings/c/src/lib.rs` header, `CONTRIBUTING.md`, `sync-about.yml`)

Verified locally: `cargo build -p wickra-c --release`, `cmake + ctest` (9/9 pass), and `-Wall -Wextra -Wpedantic` clean on gcc 13.

2026-06-09 02:14:28 +02:00

4.0 KiB

Raw Permalink Blame History

Threat model

This document describes Wickra's attack surface and the threats considered, together with their mitigations. It complements the security assurance case in SECURITY.md. Wickra is a computational technical-analysis library (a Rust core with Python, Node.js and WebAssembly bindings plus a C ABI), not a network service or trading system; the attack surface is correspondingly small.

Assets

Integrity of computed indicator values — consumers may use them in automated decisions, so silently wrong output is the primary concern.
Availability of the calling process — a library must not crash or hang its host on malformed input.
Integrity of published artifacts — the crates, wheels and npm packages users install.
The build and release pipeline and its secrets (publishing tokens).

Actors / trust boundaries

Library consumer (trusted) — calls the API with numeric data. Data may originate from untrusted sources (e.g. a market feed), so input values are treated as untrusted even though the caller is trusted.
Optional live feed — with the live-binance feature, data crosses a network boundary from an exchange over TLS.
Contributors (semi-trusted) — propose changes via pull requests.
Supply chain — upstream dependencies and the CI/CD platform.

Threats and mitigations

Threat	Mitigation
Memory-safety exploit (buffer overflow, UAF) via crafted input	Pure safe Rust; `unsafe` is forbidden/minimised, so the compiler precludes these classes.
Misuse of the C ABI FFI boundary (invalid/dangling handle, undersized batch buffer)	The C ABI (`bindings/c`) is the sole `unsafe` surface. Its shim adds no logic, NULL-checks every handle (returning `NaN`/no-op), writes only into caller-sized buffers, and catches panics so none cross the boundary. A caller passing a non-NULL but dangling pointer is undefined behaviour by C's own contract — out of scope, the same as any C library.
Denial of service via malformed/degenerate input (NaN, infinities, extreme magnitudes)	Indicators reject non-finite inputs and validate parameters at construction; update paths are exercised by coverage-guided fuzzing and unit tests for edge cases.
Silently incorrect results	100% line coverage on the core crate; reference-value tests against known-good sources; streaming/batch parity tests.
Integer overflow / panics	`clippy::pedantic` with `-D warnings`; debug assertions and overflow checks enabled in test/fuzz builds.
Adversary-in-the-middle on the optional live feed	Connection uses TLS via the platform library; transport security is delegated to that reviewed implementation.
Compromised dependency (supply chain)	Dependencies pinned (`Cargo.lock`, hash-locked CI requirements), monitored by Dependabot, audited by `cargo-deny` (advisories + licenses) on every change.
Malicious or accidental change to `main`	Branch protection requires signed commits and blocks force-push and deletion; all changes flow through pull requests with required CI; static analysis (CodeQL, Clippy) and fuzzing run on every change.
Compromised CI / leaked secrets	Workflows use least-privilege `permissions:`; secrets live only as encrypted GitHub Actions secrets; secret scanning with push protection is enabled; workflows are linted by `zizmor`.
Tampered release artifact	Releases are built in CI, tags are signed, and assets carry build provenance attestations (verifiable with `gh attestation verify`).

Out of scope

Wickra implements no authentication, authorization or cryptography of its own, stores no user data, and exposes no network listener; those threat classes do not apply.
Vulnerabilities in third-party dependencies that do not affect Wickra are tracked as exploitability (VEX) records (see SECURITY.md).

Maintenance

This threat model is reviewed when the architecture changes materially (for example, a new input family, a new network feature, or a new release channel).

4.0 KiB Raw Permalink Blame History